[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Random idea: (long, sorry =)



I seem to have rambled on a bit here, but anway...

On Thu, 30 Dec 1999, Dirk Ritter wrote:

> I guess roughly the same goes for OS/2 with the notable exception that
> it did not depend solely on those *.foo.bar extensions.

Actually, I rather liked the way OS/2 worked like that.  Granted, it
worked like that because of the EA's (which another has already posted at
length about, with several very good points about their weaknesses).

<wandering slightly off topic>
As I understood it, though, when the OS/2 people designed the Workplace
Shell, they made a very big point of makeing everything an object, and I,
for one, really liked the results.  things weren't just files represented
with pretty icons that you could move, copy, or delete, and not much else
(like so many X desktops I've tried...)

My major disappointments with OS/2 were:
a) the sever lack of ISV support (very few applications were available,
though many of those that /were/ available were very good)
b) the severe lack of IBM support (it really disturbed me that IBM didn't
care about it's OS/2 people.)
c) single user
d) TOO MANY FLOPPIES! (in fact, it was installing and re-installing OS/2
that led me to buy my first cdrom).

One of these days I'll have to try to get OS/2 running in VMWare...
</wandering>

At any rate, the reason I'm saying anything here, is because I really
/liked/ the way OS/2 knew what type a file was, and what actions you had
defined for it, and didn't give a rip what you named it.  Not only that,
but when definiing a filetype, you could say "any file with this
extention" or "any file of this type" where type was based on a template.  
I'd imagine that creating an EA or resource-fork-esque solution would have
to be done at the filesystem level, or maybe a little higher.  But, at
this point, too, it still seems like something that would only really be
beneficial in a GUI...  So then perhaps the EA/resource-fork code would
live in the GUI's libraries somewhere?

To me, it seems a hard call where to put code that would manage this; if
you use a filesystem where everything is an object (and not just a
stream), then you turn it into a filesystem thing.  if you use a "normal"
filesystem (like ext2), then you'd have to add a layer on top of it, a-la
OS/2 and FAT16 with it's "wp data. sf" and "ea data. sf" files...  But
then, in either case, you'd need a component in the GUI to interface to
either of the filesystems...

As the length of this posting is beginning to show, it gets really
complicated really quick, but the end result might be a more usable GUI.

Perhaps it's not *as* useful to have this available from a command line...  
Though I can definitely see uses for it.  In the coming months, I hope to
get a machine to install Hurd on, and learn as much as I can about it's
architecture & such...  Perhaps I'll write a translator that will do
resource forks/EAs. =)

-- 
Gregory Ade <gkade@bigbrother.net>
Find PGP public key at http://www.pgp.com (Key ID 0x63B57600)
#include <standard/disclaim.h>




Reply to: