[openbeosstorage] Re: Device API: Implementation
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Sun, 09 Feb 2003 18:29:02 +0100 CET
"Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
> I've documented the classes (I've also changed some bits) and start
> now
> with the implementation.
Very nice!
> As already discussed, a big part of the logic will live in the
> registrar. It maintains an up to date device list, sends notification
> messages for the various events and handles requests from the user
> API.
> Those requests are:
>
> * `get next device': Used for iteration. The user API sends a cookie
> and the registrar returns a device and a new cookie value.
>
> * `get device/session/partition for ID': The registrar returns a
> device
> for a device/session/partition ID.
Just to be sure: why has this functionality to be located in the
registrar=3F What is the advantage of this over having them in the
Storage Kit part of libbe.so=3F
[...]
> Since the GUI add-ons will be loaded from the user API, not from the
> registrar, the functionality can indeed be added to the real
> registrar,
> while for the time being the user API can't be added to libopenbeos,
> if
> we want to be able to test the GUI stuff. Some small hacks should
> make
> it possible for the user API to communicate with our registrar even
> when not linked against libopenbeos.
>
> I will start with the core of the registrar side implementation --
> i.e.
> with classes to manage the data -- will then implement the basic
> functionality of the user API, add notification support afterwards,
> and
> finally get partitioning and FS initialization (the latter one as far
> as possible) done.
Sounds nice! As for the FS initialization: the file system call should
be more or less the same as the mount() call.
I will add some calls to the FS API for discussion shortly, this will
also affect file system initialization.
Adios...
Axel.
Other related posts:
