|
| From: | Blake McBride |
| Subject: | Re: [Bug-apl] ISO Component File API preview |
| Date: | Fri, 11 Jul 2014 16:08:17 -0500 |
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.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.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.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.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.
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.
On Fri, Jul 11, 2014 at 12:55 PM, Blake McBride <address@hidden> 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,--blakeOn Fri, Jul 11, 2014 at 2:17 PM, David Lamkins <address@hidden> 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 <address@hidden> 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 <address@hidden> 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" <address@hidden> 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 <address@hidden> wrote:On Fri, Jul 11, 2014 at 9:58 AM, Blake McBride <address@hidden> 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
--"The secret to creativity is knowing how to hide your sources."Albert Einstein
--"The secret to creativity is knowing how to hide your sources."Albert Einstein
| [Prev in Thread] | Current Thread | [Next in Thread] |