Home   Info   DevZone   Wiki   UsersWeb  |  MainWeb  |  InfoWeb  |  DevZoneWeb  |  SupportWeb
[ ObjectOrientedFSGroup ] [ not logged in ] [ Web: Imported ] goto:  options [ get info on or edit ] [ login or new user ] [ list of topics, hubs & nodes, or recent changes ]

Here are my thoughts about an object oriented file system for JOS. There are two ways I know of that we could do this. In one approach, each file would be a serialized object, its type would be determined by the class of the serialized object, and the main actions (opening in a window, printing, etc.) would be defined in teat class. There are two primary disadvantages of this approach. First, we would have to read the whole file before doing anything with it. Secondly, this would make it difficult, I think, to interface with other operating systems.

So, I think we should have a registry of file types (defined by file extension, most likely) and the classes that implement operations on files of each type. Then a file could actually be a serialized object, but that wouldn't have to be the case.

Any comments?

-- MatthewCampbell 4-Feb-1998

I like the second idea, but why rely on file extensions for type? Do what SGI does, and establish a "magic" registry which assigns file types based on the first 4 bytes of the file. For example, the first four bytes of a .class file are 0xCA 0xFE 0xBA 0xBE, or 'CAFEBABE'. Then if that filetype cannot be found in the registry, we fall back to extensions. This way a person can REALLY tell what's in a file.

--MasonZhwiti

An approach which would be compatible with the Java Activation Framework would have some meta-data attached to each file. In addition to the usual information, the meta-data could contain a MIME type which would be used to locate the beans which can "do something reasonable" with that file (object).

-MichaelNygard, 2/27/98

Have you seen RDF (Resource Description Framework)? It provides a nice, standard way of representing meta-information about objects using XML. The file system could consist of the actual files/objects themselves, with associated RDF files describing relationships and meta-data. RDF is at http://www.w3c.org/Metadata/RDF/Overview.html

--BradNeuberg, 2/28/98

Well... Using a central registry to store the real information is good... This will allow a user to change filetype information in once place instead of many, if desired. We need to make sure though, that we will not have the same problems like Windows regarding file type conflicts etc. Our system should support several applications sharing a file type and handle them intuitivly.

And about the storing of the meta information: I have to agree with Brad. The necessary meta-data should be fetched from RDF based files. I guess we should have following cycle for obtaining file type/metadata:

RDF Description File - > Magic Keys in the file - > File Extension > Ask User

If one step fails, the system will try the next one. This has several important advantages:

1. The RDF Metadata file allows us to have a rather failure-proof system to obtain rich information about a file
2. Magic Keys and File Extensions need to be used, anyway, because operating in a heterogenous network becomes too difficult otherwise. We sometimes simply do not have the description files or even cannot create them in a network.
3. The Ask User fallback allows a user to have the last word, if the system does not know what to do. Care has to be taken, that this dialog will not be as contraproductive as the one in Windows, listing thousands of unnecessary applications, wrong/misleading application names etc. The system could e.g. show the applications/beans the user uses most on top of the list etc. to improve the situation.

Every application could provide an object that takes as input a file (datastream). The object will determine whether or not the application can handle the file. The object can base it's decision on magic values, statistical analysis or ... . Frequently used applications are -as Markus said- queried first.

It would be great if the objects supported a level of thoroughness that can be specified. The first query pass -for example- could be run on the first 1024 bytes of the file. This will be enough to rule out 90% of the file types (i.e. those with a magic number in their header). If several types remain, we can use a second pass that uses more time and more file data...

-- JeroenVanGelderen, 1.3.1998

I only really care about one capability: an application may need to store arbitrary objects as properties of file-system objects. Common ones, like Hashtables for key value pairs, might be so common as to just be built in.

I should be able to save state data on file objects by merely "assigning" it the state as a property. ACL's (Access Control Lists) are a static example of this from the DCE environment.

Someone one may want to create their own object view of a class of files, and they should be able to just "subclass" a whole file-system and give it new methods and properties.

That way several Object Relational Database Systems could independently store their objects in the native JosOOFS, and not have to write their own. They would take the JosOOFS, and extend it into XYZ-FS, and add "index properties" or "sql hints" or "binary reverse index trees".

We can't imagine what all a filesystem could be used for, so we should make it very easy to extend (or implement an interface of).

--OmegaBaphomet

If you want to go along this even further.... you would consider a file system as merely an object manager that happens to serve up "file" objects. We could then have multiple object managers in the operating system... one object manager for RDBMS, another for Very large binary files, another for small text files, etc. A default object manager could be used when the application was "unaware" that it had a choice.... it could auto-detect to see if the information being written was "small-text-like" or "large-binary-like", etc and pick the appropriate manager. Each manager could then have it's own cashe mechinism, etc. For instance, you might have a class of objects that are temporary... these objects use the "temporary" object manager. Other objects might need to be encrypted... like passwords. Some might need to be compressed, in thsi way you could have an "compression" object manager that takes (as part of its constructor) another object manager - it would merely decorate the underlying object manager with the appropriate encryption, cahsing, etc. Bottom line... leave the object manager / file system interface very simple and understand that there might not be 1, 2 or even 10 implementations, but rather hundreds based on need. Each implementation can implmenent what cool features it requires. Possibly their might be a "PropertyBasedObjectManager" that might be an interface which some, but not all, object managers might implement. Those that do not implement this interface.. could be decorated with one that does :) ? Just some ideas. Dont' be restricted with traditional views of "file system". Really, a file system is a special type of object manager... it just happens to serve up object that inherit from org.jos.File :) I can go on more here if you would like.... see ObjectManager

- ClarkEvans 2-MAR-98

I like the Metadata/registry idea, but I would like to be able to set a specific icon for a specific file in the metadata, if it doesn't have this entry the default icon for that file type would be used.

The icon-for-every-file idea should be extended to folders to it would be nive to use a "Homer Simpson" icon for my Simpson-video-games directory..

--DigiGod

Alternatively, we could try to implement Apple's Bento technology, which is used in OpenDoc.

-MattAlbrecht 10-JUL-1998

Content of these pages are owned and copyrighted by the poster.
Hosted by: