Re: [Alephmodular-devel] CFileDesc landed

[Br'fin <br...@ma...>]

On Wednesday, February 12, 2003, at 01:57  AM, Woody Zenfell, III wrote:

> 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...

Messy either way. I agree. But the function that queries for volumes 
returns a set of CFileDescs that aside from being unable to navigate up 
upon are otherwise a normal set of CFileDescs. Remember, navigate_* 
commands affect the current CFileDesc, meanwhile mucking with volumes 
is outside the scope of normal operation. :/ There's no problem with a 
unix style implementation of CFileDesc (Where the entire system is 
rooted under /) but there's a problem with Non-unix setups. Windows, 
MacOS. At the top level all your platform APIs for volumes get 
different :/

It's doable to setup something that has an innerclass that changes when 
it hits that point, but seems somehow... annoying.

(The current code is MacOS based and uses FSSpecs and accesses details 
with param-blocks, I've been debating bumping things over to FSRefs, 
but decided that could wait til after the initial CFileDescs)

>>> 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.

Yes yes.

> 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.

Ah, I didn't realize that that processing was a feature of AlephOne 
specifically. I'll have to look into it. Does A1 deal with a MacBinary 
of a map file too? Or does that still need to be explicitly split out 
into two files?

> 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'll look into it, But there is an advantage to keeping the Resource 
Manager implementation separate from a more generic method. You can 
toggle between them between builds and confirm what things are errors 
in implementation instead of errors elsewhere in the code.

-Jeremy Parsons

> 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