[REBOL] DBMS cart before the horse
From: greggirwin::mindspring::com at: 15-Jan-2002 11:50
Hi Gang,
Not to be a fuddy-duddy or anything, but we're talking about a lot of
implementation details and potential architectures, and there are a variety
of opinions from many different viewpoints. The energy this topic has
generated is terrific! Thanks to Gabriele for starting it!
Now, if I *were* to be a stick-in-the-mud, I might suggest that we lay out a
small list of requirements for this DB so we know what our target it. I know
we're sort of doing that in the other threads but I think we need to do it
more explicitly and intentionally. I've been keeping kind of quiet because
I, too, have many ideas for a database engine but bringing them up would
only derail the lines of thought even further.
I don't want to kill the energy, just focus it a little maybe. :)
If we can all agree that Gabriele is the owner, or project lead, can we
agree that he makes the final call about what gets added to the feature
list? I.e. we come up with "wish list", discuss the pros and cons of each
item, and Gabriele has final veto power (unless he doesn't want to be
burdened with that responsibility).
My top priority would be simplicity. If we can get a small "something"
working, we'll all benefit, at least to some extent, and we can improve it
over time. If we aim too high, we may end up with just "lots of interesting
bits of code".
If this makes sense to anyone, could we follow the same model we're using
now, by prefixing message topics to identify them?
Example: dbms req <topic> <sub-topic>
Example topic areas: - Example topics
dbms req general - Data types and platforms supported
dbms req limits - Number of records, record size, DB size
dbms req performance - Targets, acceptable statistics
dbms req api - Exposed functions, query interface, result format
dbms req file-format - disk format
dbms req security - log-in, encryption
dbms req transactions - transaction/rollback support
dbms req utilities - import/export, recovery, pack
dbms req docs - documentation
I don't want this to get *too* formal, as that will kill the energy we've
got going, but if we can define at least some general limits and performance
criteria, then we'll be able to look at proposed features and determine,
more easily, if they are required.
If you disagree, that's fine too. With the other things I'm doing, I may not
be able to contribute much to this project, but I'm sure I'll be around to
kibitz. :)
--Gregg
