[news.eclipse.technology.ecomm] My interpretation of your abstract model

["John F. Patterson" <john_patterson@xxxxxxxxxx>]

Scott:

I'm going to try to do three things here:

1) Provide some broad comments about differneces in perspective
2) Provide my view of the major interfaces comprising your approach
3) Use that approach to characterize how online awareness and 
conferences would be accomplished and see what questions arise.

Here goes.*

Broad comments:*

To some degree the abstract model that I originally outlined derives 
from consideration of telephony-like concerns.  The choice of terms 
(conferences) reflects that.  To some degree your approach seems to be 
more driven from computer science approaches.  The emphasis on shared 
objects and state sharing reflects that.  I do not mention this because 
I prefer either approach.  Both approaches provide insights; they are 
simply different disciplines or cultures within which people have been 
trying to solve these problems.  A big part of the challenge in a 
proposal like yours is to draw insights from all perspectives and fuse 
them into a single approach.

*My interpretation of your approach:

*At its most basic, you seem to be talking in terms of three base 
interfaces.  Let me refer to these as a SharedObjectSpaceFactory, a 
SharedObjectSpace, and a SharedObject.

_SharedObjectSpaceFactory_

This is an object that is used to create SharedObjectSpaces.  It is 
implementation neutral and can create SharedObjectSpaces that support 
alternate implementations using different protocols.  It is a 
singleton.  Alternate factories for implementing specific 
SharedObjectSpaces are plugged into (or registered against) the 
SharedObjectSpaceFactory.  When a request to create a SharedObjectSpace 
of a particular type is requested, the appropriate factory is found and 
asked to create the SharedObjectSpace that is then returned from the 
SharedObjectFactory.  This is pretty much all the factory does.  It 
supports registration of implementation-specific factories and creation 
requests.  In addition, it should support queries regarding the 
available types and the instantiated SharedObjectSpaces.

_SharedObjectSpace_

The SharedObjectSpace is a container for SharedObjects.  Clients connect 
to the SharedObjectSpace to gain access to the SharedObjects.  They 
disconnect from the SharedObjectSpace when access is no longer needed.  
Connecting to the SharedObjectSpace is the primary authenticated 
operation.  Further operations on the space and the objects it contains 
will refer back to the authenticated persona provided upon connection.  
While other operations may require permission, authentication will not 
occur again.  Connection to the SharedObjectSpace does not in and of 
itself convey any information to others about the presence of the 
authenticated persona.

A SharedObjectSpace supports the abilities to attach SharedObjects to 
and detach SharedObjects from the space.  To convey presence, a client 
attaches a presence object to the space.  From the SharedObjectSpace one 
can obtain a list of the currently attached SharedObjects.

One of the important operations on the SharedObjectSpace is the 
registration of subscriptions for information about SharedObjects.  I 
assume these subscriptions can indicate both the properties (including 
type) of a SharedObject that make its events interesting and the types 
of events that are worth reporting.  I assume that the SharedObjectSpace 
generates the actual notifications.  The "publication" of the event 
occurs when the object is attached, deltached, updated, or manipulated 
(e.g. send operation).  (While subscription for creation cannot be 
registered against the object itself, other subscriptions can be 
registered on the individual objects.  I'm still not sure what your 
position on this is, but here I've chosen to assume that only the 
SharedObjectSpace actually receives subscriptions and provides 
notifications.)
_
SharedObject_

There are many different types of SharedObjects each of which supports a 
different interface for interacting among the clients that are attached 
to the SharedObjectSpace and subscribed for the interactions.  The 
SharedObjects enforce permissions so that one client may expose a 
SharedObject, such as presence, and be assured that other clients are 
not manipulating that object.  The details of the interface for 
SharedObjects will depend on the type, but they will have properties 
against which subscriptions may be formed.  They will also have 
modifiable state that can generate events to which clients subscribe.  
Many will also support a send event that supports messaging among the 
subscribed clients without implying any state change.

*Mapping this approach onto online awareness and conferences*

_Online awareness_

To support online awareness let's assume that there is a type of 
SharedObjectSpace against which clients will register their online 
presence.  Let's call this specialization a PresenceCommunity.  To 
obtain online presence information, I connect to the PresenceCommunity 
and submit my subscription for the objects I am interested in.  In this 
case, I am asking for events related to PresenceObjects with the names 
enumerated in my buddy list.

Upon joining the PresenceCommunity, I also attach a specialized 
SharedObject called a PresenceObject.  Before disconnecting from the 
space, I detach this object.  If I want to reflect my online status, I 
change one of the modifiable properties of this PresenceObject.  Others 
learn of my presence when the PresenceObject first attaches, changes, or 
detaches, provided they have registered for these events against my 
presence.  The PresenceObject enforces permissions such that only I may 
change my PresenceObject.  Others have a read-only version of the presence.

This formulation brings to mind two questions:

1) How do we support global presence?  I think people do want this and 
as I have indicated elsewhere fracturing presence into separate 
communities raises issues about how many communities I must be in, how I 
know where other people's communities are, etc.
2) Doesn't the PresenceObject need to be more specialized than this 
implies?  First, it is critical that no one be able to spoof my 
presence, which means that the key attribute must be managed by the 
system and not simply by the client.  I suppose one might argue that 
every SharedObject might have an attacher field filled in with the 
authenticated name of the person who attaches the object.  This might do 
it and not require specialization.  But what about this?  Most 
SharedObjects must survive beyond the presence of the attaching user, 
while the presence object must not.  If I disconnect from the 
SharedObjectSpace without detaching my PresenceObject, then all clients 
must somehow learn that my PresenceObject is stale.  This implies that 
the PresenceObject is specialized to the extent that its existence is 
somehow tied to the disconnection operation.  Consider further that I 
might want to enforce reciprocity of presence and ensure that no client 
may lurk by refusing to attach the PresenceObject.  For these reasons, I 
tend to think of the PresenceObject as tied to the connect and 
disconnect operations and created and destroyed on behalf of the client 
rather than managed by the client.
_
Conferences_

To support conferences, let's assume that there is a type of 
SharedObjectSpace called a Conference.  I create the Conference, add my 
PresenceObject, and somehow make others aware of the Conference.  Then, 
they attach to the Conference and add their PresenceObjects.  To 
actually interact with each other, we attach a specialized SharedObject, 
such as a Chat object.  We use the send method of the Chat object to 
transmit messages among the participants.  In general, we subscribe to 
learn about all the SharedObjects attached to the space, including the 
PresenceObjects.  Later, we decide that we would like a voice channel, 
so one of us attaches an AudioChannelObject, then we continue to 
interact using this new object.

This formulation raises these questions:

1) How do we do invites?  Somehow we need a way to call someone into a 
Conference that they are not currently in.  We could create a Community 
through which invitations will occur, but this brings us back to the 
whole issue of multiple communities.  Now, I have to listen on all the 
communities that might contain someone who wants to call me.  This does 
not seem tenable.  Instead, it seems necessary to provide a global 
service for relaying invitations.
2) How do we negotiate streaming channels?  It is an annoying fact of 
life that communication resources require negotiation before they can be 
effectively used.  There are issues of codecs, preferred channels, and 
quality of service parameters.  I am uncertain how such negotiations 
proceed in this formulation.
3) More than the Online awareness example, Conferences bring forward 
concerns about ensuring against lurking.  Won't we want to tie 
PresenceObjects to the connect and disconnect operations?

*******

Enough for now.

jfp