Hi Gregg, Nice subject! :-)
I thought I was pulling us back from functions before storage format but I didn't back up all the way to requirements! >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. :) Definately a stick-in-the-mud view if I ever heard one, but a good idea as well. :-) >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). I can agree to that. >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". Good point. >If this makes sense to anyone, could we follow the same model we're using >now, by prefixing message topics to identify them? The list below looks like overkill for a starting place to me but the prefix model and some requirements should certainly be put forth. Not that I haven't done my fair share of "overkill" on parts of this thread already. :-) >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. A good plan. >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. :) I too am going to run into trouble with time to contribute real soon so I'm making up for it now. I'm travelling next week and will only have sporadic access and availability at that point. It sure would be great if we could all manage projects like this on an IOS Express Developer Server. :-) Thanks, Rod. Rod Gaither Oak Ridge, NC - USA [EMAIL PROTECTED] -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
