[news.eclipse.technology.ecomm] Re: Will the framework support Multi-Med

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hello,

new.eclipse.org wrote:
>     Multi-Media messages make the communications more attractive. Many
> instant messaging applications support this feature, such as MSN, ICQ (Oh,
> sametime not). I think as a fundamental framework for messaging
> communication, this feature is very important. Will the framework support
> Multi-Media messages? 

Certainly, yes.  The intent is to provide the means for a variety of 
messaging protocols to be supported through a small set of ecomm APIs.

> What protocols to support? 

Well, we intend to provide APIs that allow various protocols to be 
plugged in to interact with remote processes (servers and clients). 
This can easily by provide by eclipse extension points...so that third 
party plugin developers can actually define themselves as providers of 
ecomm functionality.

In addition, the ecomm team will definitely provide implementations of 
some of the common, open protocols...e.g. XMPP (jabber), SIP/SIMPLE, 
JMS, javagroups, perhaps SMS/MMS, others.

> What data format to use?
> How to enhence the quality of audio and vedio while keeping a good
> transferring rate. Many many aspects to be considered.

Definitely yes.  Our hope is that with the ability to have many 
protocols supported, that application and user demands will drive the 
selection of open or proprietary protocols that optimize for various 
media.  Clearly we don't want to make 'final' selections here, but 
rather provide something that application developers can use to 'mix and 
match' to support their application-specific needs WRT quality vs. 
transfer rate vs. reliability, etc.

One very successful model of this approach is that taken by the Eclipse 
team api.  Basically the team api is an abstract api for communicating 
with an arbitrary version control system.  The CVS client code is a 
provider for this api, so are commercial plugins which implement the 
team api for accessing the specific version control system of interest. 
 We would like to take a similar approach with a communications 
api...define some abstract messaging and communications interfaces, 
along with some basic constraints on system identity, security, and some 
basic notion of components within the communication session.  Then 
'plug-in' various protocols as specific implementations to allow 
interaction with compliant clients/servers...e.g. XMPP, SIP, SMS, MMS, 
sametime, groove, video/audio streaming services, conferencing 
protocols, etc., etc.


Scott



>