[news.eclipse.technology.ecomm] Re: My interpretation of your abstract m

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi John,

Thanks very much for your analysis.  I think this is a very lucid 
description of the general model that I've been using, with only some 
very minor differences/additions from what you describe.  It also points 
to some very important issues/questions that we can/will address in 
ecomm/ecf...with your help.

Comments, thoughts interspersed below

John F. Patterson wrote:
> Scott:
<stuff deleted>
>
> 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.

I agree totally.  My own background includes a heavy dose of telephony 
as well, but I have brought very much a data communications emphasis to 
this work.  Just a quick comment...I take the perspective that 'object 
state' and 'state synchronization' can encapsulate a wide variety of 
applications...both those where 'state updates' happen constantly and 
immediately (e.g. streaming audio, video, etc) and where state 
information is more abstract (e.g. objects that define a 'model' that is 
being constructed or manipulated by the user).  Of course the 
requirements for protocol performance, bandwidth, and reliability differ 
radically, but such a perspective does allow for multiple kinds of state 
synchronization.

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

Yes, exactly.  This factory pattern does provide a central api for 
constructing instances of SharedObjectSpaces, while allowing for easy 
extensibility.  In my previous work, I've made the 
SharedObjectSpaceFactory an Eclipse extension point, so that other 
plugins can register themselves as the alternate factories for creating 
new types of SharedObjectSpaces (e.g. a voice conference, access to a 
xmpp/jabber server, interaction with a legacy and/or proprietary system, 
etc).  This allows application creators to use a common api (a 
SharedObjectSpace interface, with alternate implementation), and the 
ability to modify/add to the types of spaces available within Eclipse.

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.

Yes, exactly.

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

Yes, this is correct.  Associated with every local instance of a 
SharedObjectSpace (session, container, etc) is an identity instance that 
  can be used to authenticate for access to this distributed set of 
SharedObjectSpaces.  This identity instance provides a unique handle for 
each participant within all the participating processes, and can be used 
for authentication.  Note that different types of SharedObjectSpaces 
require different types of identity, which provide different types of 
authentication.  For example, some SharedObjectSpaces may require a 
correct username/password for access (e.g. xmpp, lots of others), others 
may require a valid digital certificate, others may require a 
liberty-alliance service provider authentication token, others may 
require an ldap lookup, others may be completely open, etc).

This allows different types of sospaces to use/provide completely 
different types of authentication, as per their specific security 
requirements.

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

Yes.  I've used the term 'add' and 'remove' (because of the container 
metaphor) rather than 'attach' and 'detach', but the concepts are the same.

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

Yes.

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

Yes.  In addition to notification about sharedobject 'arrivals' and 
'departures' there is also notification available for other 
SharedObjectSpace instances 'arrival' and 'departure'.  This is group 
membership information...the space itself is responsible for keeping 
track of what the current group membership is (often referred to as the 
'view'), providing notifications to sharedobjects about changes, and 
engaging in some membership protocol to keep the membership information 
in synch (to an app-specified level of accuracy).

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

Yes.  As you say, the notion of a SharedObject allows arbitrary types to 
be created/added/removed from a given container.  SharedObject can be 
(asynchronously) notified about membership changes, arrival/departure of 
other sharedobjects...can have arbitrary state, can use the 
sharedobjectcontainer to send messages to other sharedobjects, etc.


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

Yes, in fact my early implementation of the XMPPSharedObjectSpace does 
exactly this...in this instance, the PresenceCommunity is a 
jabber-provided community...i.e. in the jabber user-namespace.

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

Yes, this is one way to implement the notion of user 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.

I suppose it depends primarily on having a single service for handling 
presence notifications for a global namespace.  That is, if the various 
IM vendors were to all agree on a single user namespace, and provide a 
common authentication protocol for access to user presence info for that 
global namespace, then it would be very easy to have a SharedObjectSpace 
that 'talked' that authentication protocol, and 'understood' 
notifications from the service about users and their presence.

The client-side implementation pales in comparison to the 
standardization required to create such a service, however...with 
interoperable server protocols for communication about user 
registrations, keeping user information, etc., 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.  

Yes...it's existence (for *remote participants*) must be dependent upon 
the disconnect operation...but remember that there can be a distinction 
between a 'primary copy' and a 'remote replica' of your PresenceObject. 
 Remote replicas of your PresenceObject(say), can be designed to 
respond to disconnect operations (or group membership changes in 
general) by destroying themselves...while your local (primary copy) of 
the PresenceObject *never* goes away (from your point of view).  That 
is, your local copy can always be present, but remote copies (of your 
presence on other peoples machines) can 'disappear' when you disconnect 
from the network...thus having exactly the user effect we expect of 
presence...that your PresenceObject on your machine never disappears 
(even when you disconnect), but your existence, state info, etc 
disappears on my machine when you disconnect...and I see your state 
change to 'not connected'.

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

Yes, it is necessary that the connect and disconnect operations be 
accessible to certain 'special' SharedObjects.  But this is just access 
to a certain functionality provided by the container, and accessible via 
the SharedObjectContext reference provided to the SharedObject upon 
addition/removal from the container.

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

Yes, exactly.

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

I think of this as an instance of the more general 'service lookup' 
problem.  That is, how are people/systems made aware of arbitrary 
'services'.  The one that's worked the best, I think, is to ride on 
existing services to communicate the availability of a new service, 
identified via an URI.  At least the URI is now understood by browsers, 
email clients, IM clients, etc.

I know this isn't a complete answer to your question, but in my previous 
work I chose to not deal with the general problem of service lookup, 
with the hope that agreement on basic web service protocols (like WSDL 
and UDDI) could help deal with this problem more generally...and with 
the ability to create containers that are accessed via URIs, so that 
invitations could be communicated among participants with already 
established services.

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

One solution is that the SharedObjectContainer (sorry about slipping the 
container word back in in place of 'space'...I just think 'space' is too 
abstract), can have an explicit 'join' and 'leave' operation.  Of 
course, various types of SharedObjectContainers can implement these 
operations in completely idiosyncratic ways...i.e. undergo a complicated 
negotiation as part of join, etc...based upon the capabilities of the 
underlying transport being used.  Same principal as the 'Socket'...with 
SSLSocket, JXTASocket, regular Sockets, etc.  Each implementation of the 
'connect' operation is different.  The idea I'm suggesting is just to 
use the same idea at a higher level of abstraction as well (at the 
SharedObjectContainer level).


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

Yes, certainly...as per the discussion of group membership notifications 
described above.

John thanks very much for these ideas and questions.  I'm beginning to 
feel convergence on a common set of ideas:  Containers/Spaces, 
SharedObjects, use of factories for providing a common api for the 
creation of an unknown/extensible set of types, etc.

I hope you don't mind if we use your idea of identifying the core 
interface as 'SharedObject' and combine that with container to have 
another core type of 'SharedObjectContainer' (along with 
SharedObjectContainerFactory).  It seems to me that SharedObject is 
nicely descriptive, clear, not overly used, and not too long.

I will make sure that we hook up at CSCW...and we can talk about these 
ideas and more.

Scott