Re: [Alephmodular-devel] CFileDesc landed

[Woody Z. I. <woo...@sb...>]

On Wednesday, February 12, 2003, at 12:10  AM, Br'fin wrote:

> Navigate_up certainly reaches a messy spot at that point. Then again it 
> might be easier to say 'No you can't navigate past the root of one 
> volume, buuuuuut, you can do this other command to find get a base root 
> object for each volume' Iiiick messy yuck. :/

This seems, to me, less clean and no more convenient nor capable than 
the pseudo-master-root approach...

>> Does resource-handling stuff include support for a stronger notion of 
>> "scenario"?
>>
> Actually, no. My current view of resource-handling stuff is that it 
> should be treated as legacy code. We need it for direct reading of 
> M1/M2/Minf files and scenarios. But I would prefer a specific format 
> specified for such things under non-mac platforms and which could be 
> the basis for the AM specific format going forward.

Oh ok, you really did mean 'resource' as in 'stuff on disk the Mac 
Resource Manager works with', rather than a more general sense of 
'external media and data AM needs to run a scenario' or the like.

A1 as you probably know has code to interpret the relevant parts and 
types of the resource fork straight from a raw resource-fork-formatted 
file, from an AppleSingle file, or from a MacBinary file.  I think that 
qualifies as a 'specific format', and better yet doesn't really require 
any conversion for existing content.

Indeed it would make sense to me to use this body of code even on 
platforms that have the Resource Manager (they could open the resource 
fork as raw data, e.g. as A1/SDL on Mac OS X does by opening 
Map/rsrc)... results more consistent/reproducible across platforms and 
all that.  But maybe I'm silly.

I don't doubt the utility of an AM-specific format in the future, nor do 
I dispute that such a format should avoid the use of resource forks.  
But whether AM has to jump directly to this future format before it can 
support non-Mac platforms...

Woody