Re: Device API: Implementation

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

When you receive a notification message, you only get IDs and need to 
retrieve the respective objects, if you want more than that. The 
required data are available in the registrar only. Well, with a path to 
a device, the API in libbe could of course directly use the 
disk_scanner functions to get the information, but that will be rather 
slow considering that the registrar has an always up to date device 
list.

> [...]
> > 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.

Very nice. I'm waiting with bated breath. ;-)

CU, Ingo