Title: Message
A taxonomy question mainly to the WSRP folks (Thomas, Mike,
...).
I think everybody is pretty much on the same page with regards to the
term "session" which identifies the transient state. (And, as Rich noted, to
people that come from an OO background, this would be the same as an object
instance).
The tougher one is the persistent key, which in WSRP is
typically referred to as "instance", but as Rich noted this may be non-intuitive
to people from an OO background (who think of transient object instances), and
hence the need for a new term.
Would you find the following, radically
simplified, suggestion for an operation
name intrusive:
createPortlet
Along those
lines, a portal would call the operation createPortlet, would get back a
(persistent) portletID and then (optionally)
call createSession with the portletID.
Note that using this taxonomy, a portlet is the "last
persistent instance". So, multiple instances of the same mail portlet are
multiple portlets.
A few justification points:
1. IBM's RPWS proposal used the term createInstance. However, clearly the
term "instance" is meaningless by itself - an instance is always an instance of
something, in this case I assume the intent was a shortcut for
createPortletInstance. Hence, createPorlet conveys a similar
meaning.
2. The ability to create a persistent key seems to be only under the
scope of WSRP and not under WSIA. WSIA supports a persistent key to create
sessions and to subsequent operations, but wouldn't probably deal with how they
are created and management (with all the associated issues that are well
described in Mike's latest summary). Hence, the motivation to use a
portal-specific name.
Any thoughts from hard-core portal people?
-----Original Message-----
From: Rich Thompson
[mailto:]
Sent: Wednesday, May 22, 2002 3:26
PM
To: ;
Subject: Re: [wsrp][wsia][wsrp-wsia joint
interfaces][Draft Spec 0.43] Terminology
Presuming the 2nd case to get dropped relative to the previous
set of
emails, I would propose this section call out
how we will refer to these
things throughout the
remainder of the document/API. In particular, I would
suggest:
Session
Information - This is carried opaquely in the interface as a
"sessionID".
=> goes away
Persistent Information - This is carried
opaquely in the interface as
a "handle".
Rather than "Manifestation", I would propose using "Entity" to
describe the
thing from which markup may be requested.
I think it has the right level of
opacity (Consumer
has no idea what kind of entity it is) while carrying
appropriate semantics (a thing that may be interacted with). Using
these
terms, there was also an open question at the
end of our last call related
to whether there were
both persistent and transient entities ...
If we are going to support explicit lifecycle for both of
these, I would
propose:
handle createEntity(handle,
propertyValues)
sessionID
createSession(handle, propertyValues)
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the
subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
