[news.eclipse.technology.ecomm] Re: Ecomm --> Eclipse Communications Fra

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi John,

John F. Patterson wrote:
> Scott:
>
> OK, so now I understand your preference for the general name.  Frankly, 
> I find it a little troubling that you want to take on so many problems 
> in a single project.  Tackling a virtualization of realtime interactions 
> seemed a worthy enough goal and, while challenging, probably feasible.

Right.  There is good reason, I think, to believe that a virtualization 
that is able to provide a general, secure, component structure for 
realtime interactions would *also* provide a reasonable model for more 
asynchronous communications.

I don't think this is a force fit at all...for example, I've built 
components to do asynchronous communications (e.g. email, threaded 
lists, etc) out of the same component model, and it has worked quite 
naturally as long as the container adds some value (such as access to a 
particular protocol).

> Perhaps the real question that I need to ask is whether you believe that 
> you will handle both asynchronous and synchronous groupware using a 
> single set of abstractions providing a common virtualization.  To be 
> specific, do you think of the SharedObjectContainer and its 
> SharedObjects as a common abstraction for implementing both conferencing 
> and discussion forums.  If so, then I am concerned about the degree to 
> which applications using the infrastructure would need to be "aware" of 
> the underlying implementation.  I assumed that the goal was to ensure 
> that applications need not be aware of the implementation on which they 
> run.

Well, my model here is the Eclipse team api.  In my view, it does add 
some value as an abstraction and API...it does allow UI creation that 
can work properly with multiple repositories...but it's not ever going 
to be completely opaque to applications...since some UIs/applications 
actually use/present to the user the specific semantics of the 
underlying system (in this case, version control).

I think a similar value can be created for communications applications. 
  It can't provide complete abstractions, but it can provide a useful 
abstraction, for aiding the development of such applications.

As an example, I've recently been working on an XMPP (jabber) 
container...and, happily, it seems that the SharedObjectContainer 
abstraction fits reasonably well with the XMPP protocol, allowing 
application programmers to write apps/uis that speak to xmpp and other 
presence/im protocols with little or no changes.

> If you are not thinking in terms of a common set of abstractions, then 
> the API becomes an aggregation of multiple APIs, say one for realtime 
> applications and another for asynchronous groupware.  This still has
> value for ensuring that issues like authentication are handled in a 
> common way, but it begs the question of which one you are starting 
> with.  

We are starting with examples from both realtime and asynchronous 
communications.  Our initial task is to choose a small but useful and 
demonstrative set.

We would definately welcome input about examples that would be most 
important to focus on from the entire community's point of view...and 
also welcome assistance with implementations for those examples.

> In this case, it might make sense to work through to completion 
> on one API before addressing the other.

Yes.  We will definately adopt this strategy.

So John...did you say that you will be in Chicago for CSCW at all?

Would you like to meet there Fri or Saturday evening?

Thanks,

Scott