Re: Resources (Re: Sed)

[johnmac@fawlty.towers.oz.au (John MacLean)]

In article <1se77t$nhh@zip.eecs.umich.edu> grover@emunix.emich.edu (Grover Thomas) writes:
>In article <C6MCCo.4pK@news.iastate.edu> irsman@iastate.edu (Ian Schmidt) writes:
>>As for Phil, users are far stupider than you can possibly imagine.  Once you
>>release something with a wider audience than just GNO users, you'll realise
>>that very very quickly.
>     I certainly agree with Ian.  As a 'stupid user' myself, I much prefer
>everything in a single file.  In fact, I'd even prefer icons to somehow be
>included as a resource, rather than the seperate "ICONS" folder.
>     Geez, using those MS-DOS systems makes me cringe, when just 1 program
>can have literally dozens of support files.
>...just a user's point of view...
>Grover Thomas       grover@emunix.emich.edu   (Nifty quotes currently down)

There is very little difference between having one file, and one directory
full of files. The file system is then the "database".
I would admit its a bit hard to find the executeable in the large list
of files.
Any copying program (including the Finder and all P8 software) can copy
directories full of files.

I would never suggest that each "resource" (such as a menu) should be
in a separate file - the overhead would be enormous.
Could you cope with two files: One containing the program, and one
containing all the "resources"?

Until we reach a stage (if ever) where the user interface description
is platform independent, I would still prefer program user interface
resources (menus, dialog boxes, etc) to live in the same file (read fork)
as the code, with integrated database support to read / write both code
and data.
Anything thats not part of the interface is data, and probably belongs
in a separate file.

If written from scratch, this implementation would satisfy almost all
requirements:
1) It would allow easy customisation, internationalisation, etc.
2) It would keep everything in one file, for easy copying, etc.
3) It would not require any special underlying file system support,
and therefore files could be easily accessed from P8, and be stored on
file systems such as UNIX and MS-DOS without special hacks.

There is no reason that such an implementation would be more/less
efficient than the current implementation (that I can see).

Of course you still have the problem of resources on data files.
As I have stated previously, I don't really think they are necessary.
Adding resources makes the data file not fully portable to other platforms
where the file system does not support resources.
This is OK for programs, because they are inherently non-portable, but
data files should be portable.
If you really needed resources on data files, there is no reason why you
can't read/write the data files using the resource database routines
(thus making the files non-portable, unless similar routines are available
on ther platforms).

I don't for a minute think we should rewrite everything, or that such
an implementation is likely/possible on the IIGS in the future.

Anyway, thats my view spelled out clearly.
I won't make any further comments (unless someone totally misrepresents me :)
-- 
Email:    johnmac@fawlty.towers.oz.au                   Phone: +61 2 427 2999
Snail:    John MacLean c/- Tower Technology             Fax:   +61 2 427 7072
          1 Apollo Place,                               Home:  +61 2 449 5930
          Lane Cove, NSW 2066, Australia.