URL's for MacOS resources?

[cr...@goingware.com]

One thing I didn't implement in the MacOSPlatformUtils is the code for reading 
XML out of a macintosh resource file.  I don't like the convention the original 
author uses for specifying a URL to a resource and I'd like to find something 
better - maybe even someone already has defined a standard.  If not, I'd like to 
know how to define one.

Macintosh files have two data streams, or forks.  The "data fork" is just like a 
regular unix or DOS file.  The "resource fork" is a structured file in which binary 
data is stored in variable-sized records, that are accessed by a 32-bit type and 16-
bit ID.  

Resources are very commonly used for storing UI elements, and since it's a 
system standard format, many resources can be edited by the end user without 
access to the source code of a program; thus Mac applications were readily 
localizable before apps on most other platforms were.

For example, you might store a menu layout in a resource of type 'MENU' and 
ID=128.  Then you can do:

MenuHandle mH = GetMenu( 128 );
InsertMenu( mH );   // mH shows up in the menu bar.

There's a freeware tool called ResEdit you could use to customize your menu text 
with.  (It's fun to write graffitti all over one's friend's application user interfaces with 
ResEdit).

Anyway, the original Mac port of the Xerces library depended on the fact that Mac 
filenames are limited to 32 characters, and could retrieve XML from a resource file 
through a kludge that goes something like this:

file:///This is a really bogus hack, being a very long filename/folder.xml?type='XML 
'?ID=128

where there is a specific long filename you specify that is matched in the 
MacOSPlatformUtils.  It's really ugly.

What I'd prefer is that the community defined a protocol type for resource files, 
something like this:

macresource://harddrive/folder/file.xml?type='XML '?id=128

where "macresource" indicates that it's a resource file URL, and not just a file: 
URL (or http:), which gets ignored on any platform that does not have resource 
files (they BeOS also has resource files, perhaps they can share the spec) and 
we can make some kind of input access method that will read a resource stream.

Regards,

Mike Crawford
GoingWare - Expert Software Development and Consulting
http://www.goingware.com
crawford@goingware.com
Michael D. Crawford
GoingWare - Expert Software Development and Consulting
http://www.goingware.com
crawford@goingware.com

     Tilting at Windmills for a Better Tomorrow