For such a thing to work, both the sender and receiver of a message need
to be able to refer to the database.  Further, the whole database needs
to be available somewhere out on the network, just in case you refer to
something that the receiver doesn't happen to still have locally.

It starts to sound like a system where all email is stored in a central
database, and your email reader just shows you a selected section of the
database.  Two difficulties.

First, there is a security problem: people should only be able to read
messages sent to themselves, messages they have sent, and (!) messages
that are quoted in messages sent to them.  Perhaps there are two quoting
mechanisms: one which lets you see the whole original message, and one
which doesn't.  Anyway, with capabilities this is all pretty simple,
actually --each message has a handle for read access, and each user can
log in and get access to a mailbox containing handles for the messages
they get direct access to.  For quoting, you create new handles that
refer to just a part of another message.

After security, there is the practical problem that the database will
grow larger over time--and someone has to pay for that disk
space!  So we want to account for how much space each user is
taking up, but keeping these accounts up to date is an interesting
problem by itself.  Just how difficult accounting will be, seems to
depend on whether you let people modify the database.

Overall it seems feasible, and it sounds interesting, although it sure
is complicated compared to the Internet's current scheme for email! 
Heck, by the time you have the above scheme, you have a lot of what you
need for something like Xanadu....

Lex



"Ken G. Brown" <kbrown at tnc.com> wrote:
> Doug Engelbart in his Colloquium at Stanford, An In-Depth Look at 
> "The Unfinished 
> Revolution",<http://stanford-online.stanford.edu/engelbart/colloquium/index.html> 
> talks of the  "Dynamic Knowledge Repository" as a place where 
> technology can be leveraged to improve mankind's *ability* to solve 
> complex problems. He talks of a system 'Augment/NLS' which has been 
> previously been implemented with extensive hyperlinking-style 
> facilities along with other features which allow far more powerful 
> ways of managing knowledge and information.
> 
> It occurred to me that all these emails could benefit from a system 
> where instead of including the quoted sections over and over again, 
> the original email could be stored in a database (or DKR) and just be 
> pointed to in full or in part via a system of tags as they have done 
> in Augment/NLS. After all, I wonder how much of the 123 MBytes is 
> just duplication.
> 
> What would be the feasibility of implementing such a system with 
> Celeste? Seems like a good database implementation would allow much 
> more efficient access. This could be extended outside the local email 
> domain to include bookmarks and notes relative to them from the net, 
> etc. too.
>     Ken
> 
> At 3:33 PM -0800 on 2/22/00,  John.Maloney at disney.com is rumored to 
> have written:
> 
> >Yep, Steve Putz and I wrote Babar at Xerox PARC and it was used
> >internally both at PARC and at ParcPlace Systems for a number of
> >years. Celeste was a simple re-implementation of Babar that I wrote
> >as a graduate student at the University of Washington. I ported it
> >Squeak, and several other folks including Mike Rutenberg and
> >Lex Spoon have added a number of important enhancements.
> >
> >I've currently got a 123 MBytes in my Celeste mail database, but this is
> >quite a bit past the point at which Celeste works well! :->
> >
> >I will probably break this into several mail archives by year.
> >Celeste works quite nicely up to several thousand messages, however,
> >and it's totally great to have a mail browser that you can modify.
> >Most important, Celeste has been extremely reliable. New messages are
> >always written by appending to the file, and in an emergency you can
> >regenerate the message index file by scanning the message file.
> >This is modeled on Squeak changes file logging; the goal is to
> >be able to recover gracefully even from something as dramatic as
> >a power failure while fetching your mail.
> >
> >Incidentally, I think it is best to think of any mail reader as
> >a mail database--the most important goal is to retain and organize
> >old messages so you can find what you want quickly. If you have
> >this, then lots of experiments can be done with the user interface
> >without risking the integrity of the mail itself.
> >
> >	-- John
> <>