Re: ISO9660/cdrom progress

"Ingo Weinhold" <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]> wrote:
> > A function is okay, although I think that "ints" scale better for 
> > priorities than a float=3D3F
> Do they=3F Be happened to use floats for priorities in the instances I 
> know (MIME sniffer rules, translators), and the nice thing about 
> floats 
> is, that you always can find a number between two given ones (as long 
> as the precision is not exhausted, of course).

Well, it looks like you are right again, I obviously have thought into 
the wrong direction :-))

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

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

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

Adios...
   Axel.