[news.eclipse.technology.ecomm] An abstract conferencing model

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

In the interests of  moving the discussion along, I offer here an 
abstract model of conferencing and ask whether and how it maps onto the 
proposed ecomm API.  This is aimed at conferencing, not 
presence/awareness.  I understand the ecomm proposal plans to address 
both of these push-related services, but I'd like to think of them 
separately for the time being.

I have left out some basic things like listeners, events, exceptions, 
and factories.  I have also not elaborated much on the methods or how to 
define or extend the piece parts.  I'm trying to keep this pretty 
high-level right now to find out if we are talking about the same ideas.

One final note, I think of this API as UI-independent.  In the 
model-view-controller sense, this is about model, not view.

OK, here goes.  I define four main interfaces:

1)  ConferenceService -- This is a machine-based container for all 
Conferences managed by the machine.  It primarily serves as a place to 
create a new Conference, be invited to join a Conference, and query 
about joined Conferences.  In some cases, it might also act as a way to 
find out about ongoing Conferences even if they have not been joined.  
Factories for constructing new conference types and new conference tool 
types may be plugged into the ConferenceService.

An interesting question is whether there is one ConferenceService (a 
singleton) for all underlying implementations or multiple 
ConferenceServices, one for each underlying implementation.  In the 
past, I have tended to assume a new ConferenceService per 
implementation, but the loss of a unified list of ongoing conferences 
(assuming you are running against mutliple implementations) might be 
regrettable.  On the other hand, managing invites and querying for 
ongoing conferences can be fairly implementation-specific.  I am 
uncertain on whether to have one ConferenceService per implementation.

2)  Conference -- This is contained by the ConferenceService.  It's 
primary job is to manage the multi-point relationship of the 
Conference.  It is not the place to actually communicate.  If you are 
familiar with telephony, this is similar to the notion of signalling as 
distinct from data transport.  In any case, the Conference is where one 
learns about ConferencePresence objects as they join and leave the 
Conference.  This is where one can leave the conference or query the 
current list of ConferencePresences.

The Conference also manages the ConferenceTool objects.  ConferenceTools 
may be created or destroyed and queried for the current list.  The 
Conference will signal an event when a ConferenceTool is created or 
destroyed by some other ConferencePresence.

3)  ConferencePresence -- This identifies a communication endpoint in 
the multi-point relationship managed by the Conference.  These objects 
are contained by the Conference.  They primarily provide attribute 
information regarding the identified presence.  They are not directly 
used to send information to the presence, i.e., there is no send 
method.  Communication is done via the Conference Tools.

The ConferencePresence object raises three interesting design questions:
a)  Should my presence be noted by the same object as other people's 
presence?  Generally, I can act on my presence, but I cannot act on 
other people's presence, so I have come to think of these as distinct 
object types.
b)  Should changes to my attributes be signalled through to others in 
the conference or should my attributes be final?  I like the idea of 
changable attributes, but it is more complicated.  (It is like bringing 
a deeper notion of presence/awareness into the conference.)
c)  Should one learn about leaving the Conference via the 
ConferencePresence?  I used to prefer this and I have come around to 
believing that one should listen for leaving in the same place one 
listens for joining, i.e., on the Conference.

4)  ConferenceTools -- This is where the communication takes place.  
ConferenceTools are contained by the Conference.  There will be 
different tools for different types of communication, e.g., chat, voip, 
app-sharing, etc.  Each tool will have a different interface depending 
on the capabilities one wants to support.  They are all sub interfaces 
of ConferenceTool.  Without diving into the details of any particular 
tool it is hard to say much about the methods that will be available.  
Presumably, all tools will have some identifying information, such as a 
name or properties.

ConferenceTools raise two interesting design questions:
a)  Should ConferenceTools be able to contain their own 
ConferenceTools?  I am inclined to say yes.  One might imagine, for 
example, a ConferenceTool that simply provides an unformatted 
communication channel among the ConferencePresences.  Then a tool that 
needed two of these could create them and contain them to do whatever it 
needs to do.  Similarly, we might have a chat tool and an app-sharing 
tool and decide later that we want a tool that always has both chat and 
app-sharing together.  This would just be a new tool containing the 
original tools.
b)  How are ConferenceTools different from Conferences?  This is an 
interesting and subtle question.  As presented above, I have assumed 
that the ConferenceTools "inherit" their multi-point relationship from 
the Conference.  In other words, if you are in the Conference you are in 
all its tools.  This is a simple policy, but it is not clear it is the 
best way to do things.  Just because someone is not able to participate 
in some tool (for example, I might not have voip installed) does that 
mean others should be precluded from using the tool.  Generally, the 
answer is that not everyone will be involved in every tool.  This means 
that we will need to provide indications of presence on the tools so 
that we can know who's in and who's out for that tool.  So, if 
ConferenceTools will also have lists of participants and lists of their 
own tools (as in a) above), how are they different from Conferences?

While there is something deeply similar about Conferences and 
ConferenceTools, I still see three fundamental differences that make me 
inclined to represent the root of the tool hierarchy different from the 
other nodes.
i)  While the ConferenceTools must somehow "track" the comings and 
goings of membership in the Conference, the Conference has no such 
requirement.
ii)  I do not think it is wise to allow the membership in the 
ConferenceTools to exceed the membership of the Conference.  I would 
consider it surprising to discover that there is someone in the chat who 
is not even a member of the containing conference. 
iii) I do not think that ConferenceTools will have a URI.  The 
Conference will be identifiable from outside the Conference, but its 
tools will only be identifiable in the context of the Conference.  This 
has a number of implications, but one of the most interesting is that 
one does not think of moving a ConferenceTool from one Conference to 
another.

I suppose these last two constraints are an imposition of policy, but 
they are policies that I am fairly comfortable with.  I might be 
persuaded to adopt a looser, more general approach, provided I could 
impose these policies when desirable.  I haven't really thought this 
through yet.

*******

I guess that's enough for now.  That should help you understand where I 
am coming from.  I hope you can help me understand the ways in which 
your proposal is similar or different from the approach outlined above.

jfp