Hi,
sorry for answering that late, but I was busy with a major restructuring
of GNU APL (APserver/shared variables).
That created a bit of an headache but is looking fine now.
Blake has asked for my opinion earlier. I am not really a database
specialist though.
The last database I worked with was Clipper (a dbase 3 compiler) in the
1990s.
My opinion is that:
1. The solution should be what the ISO standard asks for, and
2. The final decision how to achieve that should be made by the person who
is providing the code (and that is not me in this case).
The details like how many databases or files should be discussed between
users of
the component file systems and the designer(s) of it, but then decided
by the latter.
The old APL68000 had one big fat file, but at that time a second would
have killed the
harddisk and these days disk space not not an issue anymore.
My thinking related to SQL was that it should be fairly easy to use
(given Elias' SQL interface)
and not so much that SQL is performance-wise the best solution. Like
defining one 2-column
table with numbers as index and APL values as second column. That would
be 1 database with
1 table in 1 file. And maybe more files for different component file
systems. But again,
I am not a specialist (and currently not a user either).
If the solution uses database specific functions then I would try to not
use those, unless
this creates a lot of extra work.
Regarding licences, I am not a specialist either, but at least in the
past LGPL was favoured
over GPL for libraries because it made libraries more useful. Not sure
what the situation in GPLv3 is,
but I guess this has not changed.
/// Jürgen
On 07/10/2014 04:25 AM, Elias Mårtenson wrote:
I was looking at your code, and I noticed that it's SQLite-specific.
WOuldn't it make sense to make it SQL-implementation-agnostic?
Based on what I can see, the only SQLite-specific SQL you have in
there is "replace into" which I had never heard about before.
Regards,
Elias
On 9 July 2014 01:22, David Lamkins <da...@lamkins.net
<mailto:da...@lamkins.net>> wrote:
I haven't yet written test scripts, but I've informally tested all
of the functions and am reasonably confident that the component
file API is complete and correct.
If you'd like to try out the API while I'm working on scripted
test cases, the repo is:
https://github.com/TieDyedDevil/iso-apl-cf
You'll find documentation is in the comments and in Annex A of the
ISO 13751 standard.
The standard "specifies a minimal set of functions which a
conforming implementation must provide"; I've implemented all of
these. I've also added several useful functions not mentioned in
the standard, including component inquiry, component drop, and
transaction support.
Note that the code is not packaged for my package manager; I
assume that the component file implementation would become an L3
library in the event it's adopted for inclusion in GNU APL.
Júergen, I've specified the GPLv3 license since that's what GNU
APL uses. If there's a more appropriate choice of license for this
library, please let me know.
--
"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/
