|
From: | David Lamkins |
Subject: | Re: [Bug-apl] ISO Component File API preview |
Date: | Thu, 10 Jul 2014 16:28:45 -0700 |
Okay, I read the spec. It is way too minimalistic IMO. It would be best to make our component file system a super-set of that definition.
Their "Library" should map to an SQL database.Their "file" should map to an SQL table.
Satisfying the spec is insufficient. Your satisfaction of the spec must also be reasonable.
It is unreasonable to store one table per SQL database.
But *file* is an abstract notion.
Creating a native component file system is likely more effecient than riding on top of a huge database engine. That is why all of the vendors you quote did that.
The problem is that developing a native component file system is significantly more work than riding on top of SQL.
A component file system written in APL that rides on top of an SQL engine is reasonable.
A native component file system implementation would have to be written in something like C. That would be somewhat unreasonable in APL.
I've used many component file system over the years, and I've written my own file systems, so I am familiar with what they are in general terms. Having now read the spec, it is even less than I would have expected.
Are you mapping one APL component file into one SQL database? (This is what I understanding of how your system is working. If you answer this one question, I can reply better.)
I hope you don't take my directness as disrespectful. I've seen some of your work, and I respect and appreciate it.
[Prev in Thread] | Current Thread | [Next in Thread] |