"Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> 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.