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