Persistence (was Re: [e-lang] Dangling Threads and Open Issues)

Tyler Close
Tue, 2 Jul 2002 15:07:13 -0400

On Tue, Jul 02, 2002 at 10:13:31AM -0700, Marc Stiegler wrote:
> > > The decision for 1.0 is identity persistence.  In a way, this confirms
> your
> > > point. In many ways, E with identity persistence is more like a
> transient
> > > object platform than like a persistent one.  But, with a VLS (also
> needed
> > > for 1.0), it is enough like a persistent one to enable people to create
> > > persistent references to persistent objects in persistent vats.
> >
> > Not just in "many ways", but in all the important ways.  Your
> > "identity persistence" isn't anything other than a persistent
> > naming directory. It is not persistent objects. For example, I
> > don't see any meaningful way to distinguish E's "identity
> > persistence" from a Java servlet. I don't think you would call
> > Java servlets a persistent object platform.
> >
> > I don't think you can use "identity persistence" to remove the
> > "tl-" from "tl-E" and still have "E" mean the same thing. If this
> > is the direction you've decided on, I think you should come clean
> > with E actually being a transient object platform. There's no
> > shame in this, all of your current competitors are also transient
> > object platforms. Let's just be honest about the provided
> > functionality and programming paradigm.
> However big the "sea change" may be from identity persistence to automated
> ODB-style persistence, E with identity persistence is more fundamentally
> different from E with no persistence than ODB-style persistence is different
> from identity persistence. After all, with identity persistence, persistence
> is now possible :-) If one must use binary operators like 1's and 0's,
> identity persistence would have to be considered a 1. Therefore, IMHO, since
> prefixes like "tl" were designed to be binary in this sense, it would be
> more incorrect to leave the "tl" than to remove it. Having said that, I
> agree that ODB-style persistence is a sea change from identity persistence,
> which is why we invented the term "identity persistence" in the first place:
> the goal of inventing this term was to make it clear, in the non-binary
> world where better distinctions can be made, that this is a narrow form of
> persistence, and not the full-scale persistence planned for later releases.

E "identity persistence" has got nothing to do with object
persistence. E "identity persistence" is just a means for mapping
a URI to a message endpoint.  Just as a Java Servlet uses a
configuration file to map a URI to message endpoint, E uses its
"identity persistence" API. You are confusing yourself and others
by using the term "persistence" in your "identity persistence"

> Comparing it to Java Servlet persistence,

Wow, so are you actually taking the position that Java Servlets is
a persistent object platform?

> even E identity persistence is a
> superior kind of persistence, a true object persistence rather than a
> guessing game based on IP addresses:

A secure Java Servlet would be addressed using an https:// URI.
This provides similar security guarantees to a cap:// URI. Neither
of these security guarantees has anything to do with object
persistence, "true" or otherwise. A Java Servlet has to fend for
itself when it comes to saving state, and so does an E object. The
conceptual models here are identical.

> The only answer is to be clear
> about what kind of persistence we are supporting now, and what our plan is
> for the future. We have outgrown the simplicity of the "tl" label, however
> you slice it.

I understand that you wish to outgrow the "tl-" label, but the
fact is that you haven't.

The erights download page defines the "tl-" tag to mean:

"A non-persistent E is called time-local since an object only exist
as long as its hosting process does."

This is as true now as it has ever been. That it is now possible
to remap the [ URI => endpoint ] mapping is an important and
useful advance, but it is not object persistence.