FreeLists / openbeosstorage / [openbeosstorage] Re: ISO9660/cdrom progress

["Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>]

> "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
[...]
> > > But that's not enough - we don't support them correctly, we 
> > > always 
> > > have 
> > > to export all sessions, but there should be a way to 
> > > differentiate 
> > > multi-session sessions from others, so that Tracker only shows 
> > > the 
> > > last 
> > > sessions, without having to care about it.
> > > But you should always be able to mount every single session from 
> > > the 
> > > shell as it was (perhaps even from within Tracker, perhaps with a 
> > > submenu for a session=3D3F - although that would require extra 
> > > coding, 
> > > it 
> > > might be a nice solution for power-users).
> > But isn't that a feature that should be into the Tracker rather 
> > than 
> > into some API=3F I mean, the device API provides all information 
> > available. If the user wishes -- or let it be the default behavior 
> > --
> >  
> > that only the last sessions of a multi-session CD should be 
> > available, 
> > than this is something the Tracker can provide easily. Or do I miss 
> > something=3F
> 
> Perhaps :) Tracker need to have an understanding about which sessions 
> make up a multi-session volume, or else it can't offer that feature 
> to 
> the user.
> Now, only the session add-on itself know which session is part of a 
> multi-session volume, and which is not. It has to make that 
> information 
> available in some way.

Er, I probably just don't know about multi-session CDs. A CD doesn't 
simply consist of sessions, but these sessions are grouped in volumes?? 
If that is so, it should be an information the Disk Device API is able 
to provide.

> > > Yes and no - I think the fs initialization belongs to the "real" 
> > > file 
> > > system add-on, not the disk=3D5Fscanner fs module.
> > I agree. What I originally had in mind was, that the disk=5Fscanner 
> > module simply gets hold of the FS add-on and tells it to do the 
> > initialization.
> > But actually we should be able to get completely rid of the 
> > disk=5Fscanner FS modules and extend the FS add-on a bit to provide 
> > the 
> > required functionionality. Now that I think about it, I find it the 
> > preferrable solution. No code duplication at all...
> 
> Indeed, although we might want to introduce simple fs scanners at a 
> later point, when/if we find the process to be too slow or memory 
> hungry.

Agreed.

> > > So the (void *) parameter will always be a string in the future, 
> > > initialize=3D5Fvolume() can reflect that, while mount should 
> > > probably 
> > > stay 
> > > compatible with the current version=3D3F (we would only lose 
> > > source 
> > > code 
> > > compatibility)
> > I dislike using a string a bit, since that requires code to parse 
> > that 
> > string, when one could as well pass a nice structure. But I see 
> > that 
> > structures don't work very well with driver=5Fsettings.
> 
> And that structures are often fixed structures and cannot be easily 
> extended.

Right.

CU, Ingo