[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ecf-dev] [Fwd: Re: whiteboard: ECF generic or XMPP]
- From: Scott Lewis <slewis@xxxxxxxxxxxxx>
- Date: Wed, 17 May 2006 14:52:13 -0700
- Delivered-to: firstname.lastname@example.org
- User-agent: Thunderbird 184.108.40.206 (Windows/20060308)
Denis Jouvin wrote:
Hi ECF team,
I intend to build a shared whiteboard (with n participants) using ECF.
As your expertise is probably much better than mine on this subject, I
have a (newbie) question about the correct use of ECF for this purpose.
Would it be better to:
- use the generic ECF server and underlying generic protocol (btw what
protocol does it use to transmit data? defaut java serialization?), with
my own whiteboard actions and messages;
- use XMPP, with the XMPP provider, and use custom message stanzas, or
for example JEP 0009 (Jabber-RPC) or JEP 0072 (SOAP over XMPP) to
transmit whiteboard actions?
Ideally I would prefer to remain XMPP compatible, but I'm not sure if
the current ECF architecture and XMPP implementation easily allows this..
ECF does allow a common approach. One way to go about this would be to
implement your shared whiteboard application as an instance of
ISharedObject. The ISharedObjectContainer adapter is supported by both
the ECF generic provider, AND by the XMPP provider (in chat room).
Therefore apps built via these interfaces
(ISharedObjectContainer/ISharedObject) should work the same on ECF
generic or XMPP.
The way this works for XMPP is that XMPP supports 'message properties'
that can have arbitrary byte arrays associated with them. The ECF XMPP
provider serializes the Object param to
ISharedObjectContext.sendMessage(ID,Object) to a byte array, puts it on
an XMPP message as a message property, and sends it. This goes via XMPP
to receivers...any clients that do not understand the property simply
ignore the message once received. ECF clients (XMPP provider)
deserialize this byte array, and deliver the message as an
ISharedObjectMessage event to the appropriate shared object.
The ECF generic provider supports the
ISharedObject/ISharedObjectContainer adapter natively.
The main caveat here is although the XMPP provider has been tested via
the ISharedObjectContainer adapter and all of the above works, it has
not been thoroughly tested...i.e. it definately needs more testing.
There also might be rules about XMPP message sending rates (with the
magic xmpp message property) that various servers impose/enforce...I
don't know this to be true but I could imagine it. This also bears some
Note also that the datashare API has already been written to run on the
ISharedObject/ISharedObjectContainer structure (i.e. the datashare API
has been implemented on the ISharedObject/ISharedObjectContainer). So
it is also possible to write your app on the datashare API, and run it
as described above on either ECF generic and/or XMPP chat. There is a
little work here to add XMPP provider usage to
org.eclipse.ecf.provider.datashare, but the work is truly minor (and
does need to be done anyway...we just haven't gotten through with it yet).
I/we would welcome an opportunity to test out this aspect of ECF: using
these abstract APIs (ISharedObjectContainer, IChannelContainer) would
allow a single application (e.g. whiteboard) to run unmodified on either
ECF generic or XMPP (chat).
anyway thanks for your advice,