FreeLists / openbeosstorage / [openbeosstorage] Question

["Tyler Dauwalder" <tyler@xxxxxxxxxxxxx>]

You know, I'm starting to feel like we'll get these design issues
worked out a lot faster if we're actually coding in the process.

Here's my train of thought:

+ We know where we're going to have to fit into the whole OS:

------------------------------------------------------------
User level programs
------------------------------------------------------------
Storage Kit
------------------------------------------------------------
Kernel
------------------------------------------------------------
Filesystem Add-ons
------------------------------------------------------------
Physical Devices
------------------------------------------------------------

+ We know that we have to use POSIX (and BeOS extensions
to POSIX) for now, and that eventually we'll have to port whatever
we code to POSIX over to the kernel.

+ We know roughly what sorts of functions will eventually be
in the kernel API we access (thanks to the vfs docs we did).

+ We know roughly what those functions in the kernel are
going use for data structures based on the few functions
already implemented.

+ We know what functionality our classes are going to require
because it's all written out for us in the BeBook.

+ We know that writing a set of functions to abstract the 
underlying architecture (first POSIX and later the kernel) 
will be helpful if, when the time comes to finally port to the 
kernel, we've designed those functions in such a way as
to not have to change them much.

In other words, we know quite a bit. What's left is connecting
the classes in the storage kit to the underlying architecture,
i.e. implementing them. We could map that out entirely without 
writing any code (that's what I was planning to do), but I've
found that writing the little code I have the last couple of days
has been much more enlightening than staring at docs and
header files and trying to link the two together conceptually.

So what do you folks think about getting down to coding? 
Honestly, I want an answer from everybody on this one, 
because I don't want to jump the gun just because coding 
is more fun than designing. If most everyone agrees it's a 
good idea, we'll divvy up some classes and let everyone go. 
We'll each just add to the kernel interface functions as we 
go in an educated manner (i.e. using the resources listed
above) and work with each other if someone else adds a
function that doesn't quite work like you need it to, etc.

-Tyler