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
[EMAIL PROTECTED]
Michael D. Crawford
GoingWare - Expert Software Development and Consulting
http://www.goingware.com
[EMAIL PROTECTED]

     Tilting at Windmills for a Better Tomorrow

Reply via email to