[news.eclipse.technology.ecf] Re: Collaborative Applications

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi Carl,

Carl Cook wrote:
> Hi All,
>
> I have just found out about the ECF, and am very interested in helping 
> develop it the future.
>
> Just to let you all know, our research group has been developing 
> collaborative software engineering applications for the last few years. 
>  We have at present a collaborative, realtime UML class diagramming tool 
> and text editor. Both tools are for java, but they could easily be used 
> for other languages.
>
> All tools run in real time and can work on shared artifacts for any 
> number of users.  Behind the scenes is a server that holds a full 
> semantic model of the project being developed.  This server also manages 
> the users and artifacts within the project.
>
> As a benefit of modeling the project as changes happen, we can produce 
> immediate impact reports, and also alert users when someone enters their 
> "neighbourhood of related code".
>
> I see many similarities between ECF and what we have been working on, 
> and hopefully I can help the ECF project out... possibly by porting our 
> tools over to eclipse.

This would be wonderful.  Your work sounds very exciting...is it 
available in some for us to read about and/or play with?

It sounds from your quick description to be pretty close to what we've 
been doing with using the ECF 'shared object' model to distribute 
changes to EMF models.  One of the team members (Peter Nehrer) has been 
focusing on creating shared objects that can have various policies 
associated with them (i.e. via extension points) to control the runtime 
model change serialization and distribution policy...e.g. when changes 
are serialized and distribute to whom, etc.

The ECF sharedobjectcontainer model is sufficiently generic that it does 
not dictate where the authoritative copy of a sharedobject lives...that 
is, in some cases the primary copy of the sharedobject might live on a 
server process (as it sounds like your system currently does), but other 
possibilities are allowed within the 
sharedobjectcontainer...specifically that individual peers may be 
authoritative about the creation/state changes of a given sharedobject. 
 Of course, ECF containers can contain shared objects with different 
assumptions...e.g some sharedobjects may be 'server-based', others 
client based.  The interesting thing is these shared objects can share 
network resources (e.g. for communicating shared object state changes), 
and they can share access to either separate of shared user interfaces. 
 The presentation of the underlying distributed model changes are 
completely up to the application programmer.

So, for example, a single application might actually consist of a 
server-based distributed model, that updates in real time, and it may 
also consist of a 'peer-based' model that updates in real time (or not).

> One issue I see at present is that whilst it is very important to have a 
> suitable interprocess communication layer, well defined shared model of 
> the software, and smart applications, the CSCW side of things is equally 
> important.  

Agreed.

Forgive me for not reading all of the newsgroup postings,
> but has much thought as of yet gone into concurrency control, remote 
> user awareness and feedback, etc?  

Certainly a lot of thought has been given to concurrency control and 
multithreading by me and others on the team...in that the provider 
implementation support basic failure detection and reporting...which is 
critical for keeping distributed state synchronized .

RE: remote user awareness, etc...our initial (very small) set of 
applications have been focussed around real-time user presence/awareness 
updates, real-time chat, shared editors, and such.  We've also 
implemented an xmpp (jabber) provider, and a very very simple Jabber IM 
client.  We are hopefull that we will soon be doing more work 
specifically on providing abstract APIs for communicating things like 
user presence.  We would like to provide such apis in a completely 
cross-protocol way (i.e. so that application programmers would only need 
to interact with a 'presence component'...and this presence component 
could then use xmpp, or other protocols to actually communicate the 
presence info to others.

If not, hopefully I can be of some
> help to the application developers, and maybe even the core ECF platform 
> developers if user awareness is built into the core structure of ECF.

We are just beginning to think about creating various components (and 
associated APIs) for higher-level concepts like user awareness, 
distributed model distribution and update policies, file sharing, other 
interesting app domains like application sharing, chat, etc.  There are 
actually a fair number of 'communications components' that one can come 
up with...and we think that the notion of a container and 'shared 
objects' (basically and java object with any code and state) provides a 
good distributed component model...particularly when combined with the 
OSGI bundle and service model.

> If anyone is interested in talking to me about shared SE tools, feel 
> free to post to this group or email me directly.  I will post a screen 
> shot of my latest tools to:
>
> http://www.cosc.canterbury.ac.nz/carl.cook/sevg/toolsSS.png,
>
> and here are a couple of recent papers related to our work:
>
> http://www.cosc.canterbury.ac.nz/carl.cook/papers/apsec04CAM.pdf
> http://www.cosc.canterbury.ac.nz/carl.cook/papers/acsc2005.pdf

Thanks Carl...I will take a look as quickly as possible.  If I don't get 
 immediately back to you it's not because of lack of interest...but 
only because of lack of time ;-).  So please contact us directly (email 
to me at slewis@xxxxxxxxxxxxx, etc).  If you are able and willing to 
participate on ECF (i.e. able to make your work available under EPL) 
then I'm sure we would be able to work out a way to have it/you advance 
ECF development.

> (I have noticed the names of a couple of Collaborative SE researchers in 
> the newgroup postings already!).

Yes, in a former life I did some collaborative systems research (e.g. 
cscw etc)...and we somehow seem to stick together :-).

Thanks...please do keep in direct touch and let me know what sort of 
effort you would be able/willing to engage in assisting with the ECF 
project.  Although we want to keep the project reasonably small, there 
are a lot of different threads and sub-projects that we would like to 
attack and don't currently have the resources to do so...so your 
participation would be very welcome.

Thanks,

Scott


> Kind regards, I look forward to working with this project, and I hope it 
> all goes well!
>
> ~Carl Cook,
> University of Canterbury, NZ.