Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!well!shf
From: shf@well.UUCP (Stuart H. Ferguson)
Newsgroups: comp.sys.amiga.tech
Subject: Re: RESOURCES (as in disk-resources)
Message-ID: <5895@well.UUCP>
Date: 7 May 88 01:30:43 GMT
References: <8805040914.AA24466@cory.Berkeley.EDU>
Reply-To: shf@well.UUCP (Stuart H. Ferguson)
Organization: The Blue Planet
Lines: 104
Summary: Looks good -- more details please

Stuff about resource files:

>                PRELIMINARY DOCUMENT.  COMMENTS PLEASE!

>    In general, the main idea is to be able to specify all sorts of useful
>    information, both for the program which uses the resources, and for the
>    user to ALLOW HIM TO MODIFY the resources.  IFF does not cut it, as
>    you will soon see.

Generally, it looks like a really great idea.  It would be really useful
even just for programming purposes to be able to define things in a
better way than static structures, or custom code to build dynamic
structures. 

Contrary to your claim, however, I did not see how IFF doesn't cut it.  
IFF just provides a standard way of storing chunks of bytes in a file -- 
you get to say what the chunks mean.  I don't see why you can't wrap up
what you've devised into a CAT or LIST of FORM RSRC or something like
that.  You don't have to like it, but it IS the standard after all. 

>    A basic requirement is to remove ALL WORK from the application program
>    which uses the resources.  

Right attitude.

>                               That is, the program should be able to
>    simply GetRes(handle, "titlebitmap") and the call would return a
>    completely resolved BitMap structure for use in its title screen.
>    Structures which the programmer used to have to build by hand in
>    static declarations can be made into resources and resolved
>    automatically.

This sounds really great, but things got a little opaque after this
point in the document.  Can you explain a little more about the
internals of your design?  Given that I only kind of half understood it,
my remaining comments may or may not be meaningful.

>    how:        bitmask of search areas (0 highest priority).  Usually
>                -1 is specified.
	:
>    area:       0       resources contained in this executable
>                1       specified resource file (default:procname.rsrc)
	:
	:

Hmm.  How are you going to get at the resources stored *in the
executable*?  Also, will GetRes() end up searching every level for
things?  How do you plan to keep this fast (especially with the current
DOS)? 

>    RESINFO:
>        Resource Information.  NOTE that the resource data block is for

Interesting, but not very illuminating.  How about some more about this?

>    STRINFO:
>        Information about a structure.  Any referenced or subreferenced
>        structures are included.  All structure ID's are renumbered
>        according to their entry #, starting at ID 1.

I take this to mean that each STRINFO refers to one complete structure, 
and that any structure pointers that a structure contains are resolved 
by using the ID tags internal to this instance of STRINFO.  Sounds 
semi-reasonable, I suppose, if this is actually what you meant.

>        [0] = # of entries.  Each entry takes 2 array spots.
>        [1] = master structure name     [2] = structure format
>        [3] = structure name            [4] = structure format

Does this mean that if structure A contains a pointer to structure B, 
then the STRINFO for A contains the format for A and for B?  What if you 
want to refer to structure B by itself, do you need a separate STRINFO
for that as well?  Seems innefficient and prone to problems.  If the
"structure format" for the same structure appears several places you'll 
need checkers to make sure all the structure definitions are the same.  
Why not have each structure defined exactly once and refered to only by 
reference from then on?

>        the structure format is not defined in this document.

Get it on paper quick if you haven't already.

>STRUCTURE FORMAT, GENERAL CAPABILITIES:
>    Structure ID's are tagged in bits 15 and 14 as follows:
...
>        01 - parent pointer     (rest of ID not used)

What if two higher-level structures point at this struct?  How does it 
tell which is the parent?  Seems like you need to use the ID for this 
case as well.

>RESERVED STRUCTURE NAMES:

An awful lot here.  How big is the resource file which defines all these 
going to be, and how fast will it be to read?  My fear in looking at 
this is that the resouce.library (?) will have to be a mini-compiler and 
reading all the structure definitions will take the kind of memory and 
time that a compiler takes.  Obvoiusly, since I don't know the internals 
my fears are probably ungrounded.  Please say something about efficiency
issues in your future postings. 

Good work!
-- 
		Stuart Ferguson		(shf@well.UUCP)
		Action by HAVOC		(shf@Solar.Stanford.EDU)