Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

DBMS cart before the horse

 [1/7] 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

 [2/7] from: rgaither:triad:rr at: 15-Jan-2002 15:22


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
<<quoted lines omitted: 3>>
>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
<<quoted lines omitted: 11>>
>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 [rgaither--triad--rr--com]

 [3/7] from: jason:cunliffe:verizon at: 15-Jan-2002 15:30


In case is fell off the recent intense db design radar, I offered to put up a Vanilla site for dbms3r project if people think that might help. My orginal [long] post is at: http://www.escribe.com/internet/rebol/m18623.html This can help to focus effort, but also not waste all the related good ideas and references which the discussion produces. ./Jason btw: Any idea why google searches don't seem to see the rebol list archives?

 [4/7] from: greggirwin:mindspring at: 15-Jan-2002 16:11


Hi Jason, << In case is fell off the recent intense db design radar, I offered to put up a Vanilla site for dbms3r project if people think that might help...This can help to focus effort, but also not waste all the related good ideas and references which the discussion produces. >> I haven't but peeked briefly at Vanilla, but I'll follow wherever the project goes. --Gregg

 [5/7] from: greggirwin:mindspring at: 15-Jan-2002 16:15


Hi Rod, << The list below looks like overkill for a starting place to me but the prefix model and some requirements should certainly be put forth. >> Yeah, I was just trying to give lots of examples, thinking that if I didn't, someone would come back with "but what about...". :) << It sure would be great if we could all manage projects like this on an IOS Express Developer Server. :-) >> I couldn't agree more. :) --Gregg

 [6/7] from: rgaither:triad:rr at: 15-Jan-2002 22:25


Hi Jason,
>In case is fell off the recent intense db design radar, I offered to put up >a Vanilla site for dbms3r project if people think that might help. > >My orginal [long] post is at: >http://www.escribe.com/internet/rebol/m18623.html > >This can help to focus effort, but also not waste all the related good ideas >and references which the discussion produces.
I remember the offer and like Gregg don't know much about Vanilla but would follow the thread if thats where it moves. Thanks, Rod. Rod Gaither Oak Ridge, NC - USA [rgaither--triad--rr--com]

 [7/7] from: g:santilli:tiscalinet:it at: 17-Jan-2002 22:12


Hello Gregg! On 15-Gen-02, you wrote: GI> Not to be a fuddy-duddy or anything, but we're talking about GI> a lot of implementation details and potential architectures, GI> and there are a variety of opinions from many different GI> viewpoints. The energy this topic has generated is terrific! GI> Thanks to Gabriele for starting it! I didn't really expect to start something like this. :) I just need a simple dbms, and I don't want to reinvent the weel. GI> that we lay out a small list of requirements for this DB so GI> we know what our target it. I think we should do a thing at a time. I want to focus on the low level data handling functions now, since that is the weak part of dbms.r... GI> because I, too, have many ideas for a database engine but GI> bringing them up would only derail the lines of thought even GI> further. As I said, I'm dreaming of something too (if you look inside dbms.r, you'll see I've also got a name for it, ADaStReS - Advanced Data Storage and Retrieval System) but I've got no time for it currently. GI> My top priority would be simplicity. If we can get a small That's my top priority too! Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted