Well... I'm done. Clearly we can't agree agree on either the concept of a file or how a spec should be interpreted.
On Fri, Jul 11, 2014 at 2:08 PM, Blake McBride <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >>> 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 <[email protected]> >>>> 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 <[email protected]> >>>>> 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" <[email protected]> >>>>>> 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 <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> On Fri, Jul 11, 2014 at 9:58 AM, Blake McBride <[email protected] >>>>>>>> > 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/ >> > > -- "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/
