Re: ISO9660/cdrom progress

> 
> "Ingo Weinhold" <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]> wrote:
> > > We should also have priorities for the file system modules (i.e. 
> > > a 
> > > UDF 
> > > file system should always get the disk, not the ISO-9660 file 
> > > system, 
> > > if possible).
> > That shouldn't be hard. We can add a function returning the 
> > priority 
> > to 
> > the FS module interface.
> 
> A function is okay, although I think that "ints" scale better for 
> priorities than a float=3F

Do they? 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).

> > > Also, how does the system deal with multi-session CDs (and the 
> > > like)=3D
> > > 3F 
> > As it does right now, via the session modules.
> 
> 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=3F - 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? 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?

> > If you mean, initializing a FS and writing partition tables, then 
> > that's what the original DriveSetup add-ons were doing. The only 
> > problem is, that both tasks need add-on-specific parameters, that 
> > in 
> > the case of the DS add-ons is retrieved from the user by popping up 
> > a 
> > dialog. The only way, I see, is to create a separate DS add-on API 
> > for 
> > this.
> 
> Yes and no - I think the fs initialization belongs to the "real" file 
> system add-on, not the disk=5Fscanner fs module.

I agree. What I originally had in mind was, that the disk_scanner 
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_scanner 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...

> So if there is a DS add-on for a specific file system, it can provide 
> a 
> special GUI, but if not, DS will just ask for a name and pass that 
> one. 

Sounds good.

> I want to have mount/initialize use the driver=5Fsettings so that you 
> can 
> have sticky mount settings, etc.

Yes, that's nice.

> So the (void *) parameter will always be a string in the future, 
> initialize=5Fvolume() can reflect that, while mount should probably 
> stay 
> compatible with the current version=3F (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_settings.

CU, Ingo