Although my implementation may not meet what you perceive to comply with their unwritten (hidden) intent, my implementation would meet their written spec.
On Fri, Jul 11, 2014 at 3:36 PM, David Lamkins <da...@lamkins.net> wrote: > 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/ >
