Returned mail: Unable to deliver mail

[Mail Delivery Subsystem]

   ----- Transcript of session follows -----
<<< RCPT To:<dmarer@td2cad.intel.com>
<<< DATA
554 sendall: too many hops (17 max)

   ----- Unsent message follows -----
Received: by td2cad (5.57/10.0i); Sun, 14 Mar 93 17:10:30 -0800
Received: from whistler.sfu.ca by hermes.intel.com (5.65/10.0i); Sun, 14 Mar 93 17:06:07 -0800
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA19427; Sun, 14 Mar 93 17:04:10 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from drakkar.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA08997; Mon, 15 Mar 93 02:04:02 +0100
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA08634; Mon, 15 Mar 93 01:45:29 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA18839; Sun, 14 Mar 93 16:41:03 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from drakkar.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA08559; Mon, 15 Mar 93 01:40:50 +0100
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA07210; Mon, 15 Mar 93 00:35:59 +0100
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA17084; Sun, 14 Mar 93 15:32:23 -0800
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from drakkar.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA07132; Mon, 15 Mar 93 00:32:16 +0100
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA14520; Sat, 13 Mar 93 11:15:14 +0100
Return-Path: <MAILER-DAEMON@uunet.uu.net>
Received-Date: Sat, 13 Mar 93 11:15:14 +0100
Received: from relay2.UU.NET by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from dmi.ens.fr by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA20271; Sat, 13 Mar 93 05:15:07 -0500
Date: Sat, 13 Mar 93 05:15:07 -0500
From: MAILER-DAEMON@uunet.uu.net (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <9303131015.AA20271@relay2.UU.NET>
To: <rideau@clipper.ens.fr>
Sender: rideau@clipper.ens.fr

   ----- Transcript of session follows -----
550 <moose-programmers%davgar%sfu.ca,@uunet.UU.NET>... Host unknown

   ----- Recipients of this delivery -----
   <david%davgar@uunet.UU.NET>
   <moose-programmers%davgar%sfu.ca,@uunet.UU.NET>

   ----- Unsent message follows -----
Received: from dmi.ens.fr by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA20264; Sat, 13 Mar 93 05:15:07 -0500
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from brick.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA14495; Sat, 13 Mar 93 11:14:59 +0100
From: rideau@clipper.ens.fr (Francois-Rene Rideau)
Message-Id: <9303131014.AA14495@clipper.ens.fr>
Subject: Re: Obj. Sharing (djg3) far17
To: david%davgar@uunet.uu.net
Date: Sat, 13 Mar 93 11:14:57 MET
Cc: @sfu.ca@dmi.ens.fr, moose-programmers%davgar@uunet.uu.net
In-Reply-To: <2b9ae07a.davgar@davgar.UUCP>; from "davgar!david" at Mar 8, 93 12:58 am
X-Mailer: ELM [version 2.3 PL11]


>> 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.
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).

>> 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.

>> 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.

>> 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.

>> 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.

>> -- 
>> 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