Re: Device API: Implementation

"Ingo Weinhold" <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]> 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.