FreeLists / openbeosstorage / [openbeosstorage] Re: session module

["Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>]

> Tyler Dauwalder <tyler@xxxxxxxxxxxxx> wrote:
[...]
> > Yes! (I think I've mentioned I really like BeOS' cdda file system :
> > -) 
> > Incidentally, most of the work a cdda file system would need to do 
> > is 
> > already handeled by the session module, I believe.  When it comes 
> > time 
> > to do a such a file system, the code of interest can be pulled out 
> > and 
> > shared fairly easily if so desired.
> 
> Oh yeah, I like that, too! :-)
> Perhaps we can even have registrar (=3F) 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.

> We could even integrate cddafs and cddblinkd databases, so that the 
> audio CD doesn't even have to be mounted to get recognized and its 
> names updated :-)

Yes, that would be cool.

> We could ask Marco if he would release the source to his cdda-fs.

If he is allowed to do so...

> > I haven't checked yet, but it's possible that the Mac partition 
> > information is stored in the first 16 blocks of the ISO file system 
> > (as 
> > you may recall from that lovely iso9660 standard, those blocks are 
> > reserved for "system use", and are usually just zeros; plus the 
> > first 
> > address listed for the Mac partition was block 1).  In that case, 
> > the 
> > Mac partition would be recognized first (given a proper Mac 
> > partition 
> > module), and subsequently the HFS file system would get recognized 
> > (wherever it's hidden).  Otherwise the ISO file system just gets 
> > recognized.  That seems like a resonable expected behavior to me.  
> > I'm 
> > not sure I like the idea of letting both partition modules and file 
> > system modules have an equal go at the session data; letting the 
> > partition modules have the first crack at it like we currently do 
> > seems 
> > better.
> 
> 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.

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.

CU, Ingo