WIth all due respect, Blake, I understand and appreciate the differences between filesystems and databases.
I've already said my piece regarding some of the benefits of using files rather than a database; I won't reiterate. To be clear: I have no objection to your creating this code. I object to accepting your proposed implementation in satisfaction of Annex A of the ISO APL spec. Innovation is a good thing. However, when your task is to implement a system which conforms to a standard, it is your duty to fully understand the standard and the unstated assumptions upon which the standard's author(s) constructed their requirements. The issue is not whether a database provides advantages that a filesystem lacks. The issue is that no component file system in the history of APL has ever used used a database server as a storage layer. There's no doubt in my mind that the authors of the ISO APL standard intended for a component file system to use the host's filesystem for storage. Standards codify existing practice; they do not speculate about fresh new designs. Please do go ahead and implement your components-on-SQL proposal. I truly believe that it will find general use and acceptance. But please don't try to replace the standard's component file system with an invention which is clearly *not* a component file system. On Fri, Jul 11, 2014 at 12:55 PM, Blake McBride <blake1...@gmail.com> wrote: > David - SQL offers many features that are very, very important in the real > world. Creating file systems on top of SQL that are compliant to start off > with, but have the potential to be augmented for real-world situations is > extremely valuable. For example, the way you implemented component files > as one-table-per-database means that it is not possible to have > transactions with more than one table. Often, an application wants to > update several tables that relate to each other. SQL guarantees that they > all make it, or they all don't. This means the database operation is > atomic. It keep all the files consistent. They way you implemented the > component file system, this can never be accomplished. > > Another point is the number of files. Many real-world applications have > hundreds of tables/files. With SQL you only need one handle to the > database (all of the files). Implementing as you have done, you would > need separate handles to each file. Also, are you going to burden the Unix > system with all those apps connecting to all those files? Or, are > you limiting your implementation to toy applications? > > Another point, multi-user simultaneous access. If you are tring to update > several tables you'd have to exclusively lock each one, do the update, > flush the file system, and release the lock. It makes all file access > (between multiple-users) sequential. SQL solves these problems. > > Another point, if you use component file name = Unix file name, how are > you going to prevent one APL application from clobbering another (by using > the same name)? With SQL they'd use different databases and there would be > no problem. > > The list goes on. I understand that you spent a lot of effort in your > implementation, and it is appreciated by me and others. I mean no offense > with my proposal. I really think this is the right thing for all of the > many reasons I've given, plus many more I haven't mentioned yet. > > Respectfully, > > --blake > > > > On Fri, Jul 11, 2014 at 2:17 PM, David Lamkins <da...@lamkins.net> wrote: > >> That's what I thought you had planned to do. >> >> My objection stands. A table in a database is not a file. >> >> >> >> On Fri, Jul 11, 2014 at 11:56 AM, Blake McBride <blake1...@gmail.com> >> wrote: >> >>> There would be an association between the name passed to CF_OPEN and an >>> SQL table with that same name. >>> >>> >>> On Fri, Jul 11, 2014 at 1:54 PM, David Lamkins <da...@lamkins.net> >>> wrote: >>> >>>> If I understand your proposal (and I may not), my objection is that you >>>> don't intend to associate the name passed to CF_OPEN or CF_CREATE to a >>>> like-named file in the host filesystem. >>>> On Jul 11, 2014 11:40 AM, "Blake McBride" <blake1...@gmail.com> wrote: >>>> >>>>> I don't understand. What I am proposing to create is something that >>>>> conforms with the APL Annex standard. It will be implemented on top of >>>>> Elias' SQL interface. It will be implemented in a way that is also >>>>> cooperative with the design and intend of SQL (since that is what it rides >>>>> on). What part of it is not a component file system? >>>>> >>>>> >>>>> On Fri, Jul 11, 2014 at 1:26 PM, David Lamkins <da...@lamkins.net> >>>>> wrote: >>>>> >>>>>> On Fri, Jul 11, 2014 at 9:58 AM, Blake McBride <blake1...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Does that sound agreeable to everyone? >>>>>>> >>>>>>> >>>>>>> >>>>>> Not at all. What you're proposing to create is not a component file >>>>>> implementation. >>>>>> >>>>>> -- >>>>>> "The secret to creativity is knowing how to hide your sources." >>>>>> Albert Einstein >>>>>> >>>>>> >>>>>> http://soundcloud.com/davidlamkins >>>>>> http://reverbnation.com/lamkins >>>>>> http://reverbnation.com/lcw >>>>>> http://lamkins-guitar.com/ >>>>>> http://lamkins.net/ >>>>>> http://successful-lisp.com/ >>>>>> >>>>> >>>>> >>> >> >> >> -- >> "The secret to creativity is knowing how to hide your sources." >> Albert Einstein >> >> >> http://soundcloud.com/davidlamkins >> http://reverbnation.com/lamkins >> http://reverbnation.com/lcw >> http://lamkins-guitar.com/ >> http://lamkins.net/ >> http://successful-lisp.com/ >> > > -- "The secret to creativity is knowing how to hide your sources." Albert Einstein http://soundcloud.com/davidlamkins http://reverbnation.com/lamkins http://reverbnation.com/lcw http://lamkins-guitar.com/ http://lamkins.net/ http://successful-lisp.com/
