[openbeosstorage] Re: session module

"Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
> > Oh yeah, I like that, too! :-)
> > Perhaps we can even have registrar (=3D3F) add-ons that take over the 
> > job 
> > of cddblinkd :-)
> > But of course, we could just let it run as a separate server as 
> > well 
> > (now without polling, since the new API allows for notifications :-
> > )
> It's probably not a bad idea to introduce a dedicated server that 
> allows to add user add-ons with code that would otherwise be run in 
> separate daemon. It should not be the registrar, I think, since it is 
> `mission-critical', and one should better not need to risk the 
> usability of the system when trying a third-party add-on.

Indeed, that's very true. Something like inetd for generic services :)

> > We could ask Marco if he would release the source to his cdda-fs.
> If he is allowed to do so...

Sure, that would be an important premise.

> > That sounds very reasonable! Then it's a matter of priorities which 
> > partition module gets there, first.
> > Although in the case of iso9660 vs. HFS, normally HFS should be 
> > preferred, because it allows for more information to be stored 
> > (like 
> > file types, long file names etc.).
> Nooo! I have the vague feeling you're trying to tease me. ;-)
> This has nothing to do with priorities and couldn't be solved by 
> using 
> them. I'll try to explain again:
> 
> The session in question is partitioned Apple style and when looking 
> at 
> the partition(s) defined by it, we find a HFS formatted one. At the 
> same time, when considering a virtual partition spanning the whole 
> session (i.e. as if the session wasn't partitioned according to any 
> scheme) we discover an ISO9660 volume on it. This works, since, as 
> Tyler explained, the ISO9660 FS ignores the first 16 logical blocks, 
> and that is where the Apple partitions are described.

I was not trying to tease you, really, I was just dumb :-))

> So, in fact only one partition module is in the game in the first 
> place 
> (unless you count the `virtual' partitioning, which is merely a 
> fallback). Hence priorities for partition module won't have any 
> effect 
> in this situation. And in the current implementation partition module 
> priorities are not included; for FSs they are, though.

Yes, and that should be in fact enough.

Adios...
   Axel.

Other related posts: