Obj. Sharing (djg3) far17

[David Garfield]

On Sat, 13 Mar 93 11:14:57 MET, "Francois-Rene Rideau"
<rideau@clipper.ens.fr> wrote:
> >> A possible means of making data objects available to other processes:
> >>
> >> It is possible for
> >>
> >>    1) All processes to be objects.
> >>    2) Objects to be in the logical file system.
> >>    3) Objects themselves be asked what objects are below them in the
> >>       file system.
>
> I think we agree, but I'd like to modify what you said:
> 1) EVERYTHING is an object; processes in particular.

agreed.

> 2) I'd rather say the file system is included in the object system
> (objects are files is the unix philosophy: you have only files,
> and even to send/receive one integer number, you are bound to
> use a (preferably ASCII) file).

Either the file system is the object system or the object system is
the file system.  Either way they are the same thing.  Which one
doesn't really matter.

> >> With this setup, each process object is placed in the logical file
> >> system.  Each process object may then be queried as to what public
> >> objects it contains.  If a process is a 'dumb' program, this would
> >> probably mean either nothing is public or a fixed list is public.  A
> >> 'smart' program could either published all its objects or a portion of
> >> its object list it selects.
> The FS directory equivalent becomes what I previously called the dictionary.
> You can even publish part of an object, that is, only part of its methods
> are available. As each object has its dictionary, you can publish different
> things to each of them.
>
> >> As an additional capability, a 'smart' program could have objects
> >> placed into the directory that it provides by other programs.  This
> >> could be used as a means of specifically requesting communications
> >> with a process.
> I'm not sure of understanding what you said, but modifying an object
> in a dictionary is a sure means of communication to all those who
> read this dictionary. Also see my discussion with Peter Mueller about
> naming.

This point is that program A can place object B into the directory
provided by program C.  Thus dictionaries may be written to by things
other than their provider.  Of course, the directory provider will
have to manage (and allow in the first place) the placement of an
object into it by a foreign process.

>
> >> Additionally, if an object can be placed in one place in the file
> >> system, it can be placed in other 'known' places, allowing for the
> >> publication of objects.
> That's the multiple dictionaries I ask for.

ok.  Directories/Dictionaries must also be hierarchical.

>
> >> One other capability allowed by mapping between directories and
> >> objects is that something like a ZIP file (produced by PKZIP or the
> >> like) could allow its contents to be directly accessed as a file.
> >> Mapping between different styles of file systems could happen the same
> >> way (assuming you want to nest filesystems).
> Dictionaries should be a virtual object class, with standard methods, then
> anyone could implement a new way of accessing objects. They also should
> have a recursive definition, so that dictionaries can be part of another,
> and there's no problem in mixing dictionary methods.

Actually, I almost think that the abstract directory class is the base
of the object hierarchy.

>
> >> Note on terms:  I am using the term 'logical file system' to refer to
> >> the effective file system that exists when the system is running.  In
> >> Unix this is composed of the the root file system and any file systems
> >> and network file systems mounted on it.  In the case of Moose, the
> >> logical file system will (I hope) also include objects and other
> >> things.
> Each of us has his own terminology, inherited from his past experiences
> and thinkings about computing. Let's not fight for names.
> But if I prefer the object terminology to the file terminology, it's because
> under existing systems, files are a closed inextensible system, with a
> unique implementation oriented toward big file managing. Objects are
> a generic extensible concept, which includes huge structures as well as
> basic data.

I defined my terms so that everyone else would know what I was talking
about.  I expect everyone to know what I mean when I say 'file
system', but will they know just what I mean when I say 'logical file
system'?  I have no objection to using the object terminology, but
will argue that they should be equivalent in implementation.  I would
argue that we should support files as objects, and that files/objects
should have all kinds of varied capabilities.

>
> >> --
> >> David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
> >> Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com
>
>    ,
> Fare -- Franc,ois-Rene' Ba^n Rideau D+a(.ng-Vu~ --
> 45 rue d'Ulm 75230 Paris cedex 05 FRANCE. Tel:(1)43.25.19.55
> rideau@clipper.ens.fr
>

-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com