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

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi John,

John F. Patterson wrote:
> Scott:
>
> While I agree with your desire to change the name and I like a lot of 
> the changes to the description, I was hoping there would be a little 
> more conversation before the name got changed.
>
> My specific problem is that the term communication seems overly 
> general.  Do you expect to support email?  Do you expect to support 
> netnews or discussion forums?  

My answer to these is 'yes'.  I think it's reasonable that this project 
try to produce an extensible framework to support as wide a range of 
communications protocols (and associated applications) as possible.  My 
observation is that frequently, such efforts result in APIs that 
introduce new, incompatible protocols.

I'm hoping this project will be different.  That is, I think we should 
focus on producing software abstractions that allow the runtime 
selection and use of a variety of protocols, both for communicating with 
existing services (e.g. email, web-based services, netnews, etc), and 
for communicating directly with other people in 'real-time' 
(conferencing, etc).  Although these types of communications do differ 
in the details of their protocols, they also share a number of common 
characteritics (e.g. need for authentication, reliability, 1-1, 1-many, 
many-many delivery, message ordering, need for component apis, etc).


So far, my impression has been that you
> are focused on "realtime" collaboration.  Is that correct?  I could be 
> wrong.  I have seen the term asynchronous used in a few places.  I have 
> interpreted this as a reference to asynchronous messaging (as opposed to 
> query/response) rather than a reference to asynchronous groupware.

I think there are two good reasons for being 'biased' toward realtime 
applications:  1) I think the evidence is that they have a high 
potential for being attractive applications for Eclipse users and also 
for developers;  2) It seems to me that many of the 'hard problems' for 
programming communications applications are represented by 'realtime' 
applications.  Performance, scalability, reliability, security, state 
synchronization, are all relatively difficult in these applications.

Now I don't think this means we should focus exclusively on real-time 
applications.  Actually, I think we will implement integration with some 
non-real-time communications services...perhaps email, peer file 
sharing, team blogging/web page construction, or RSS.  Hopefully other 
developers will use ECF to do the same for their favorite protocol and 
associated service.

I do admit to a personal bias for person-to-person real-time 
communications...a bias which is happily *not* shared among all the ECF 
team members.

> Without a doubt ECF is better than ecomm, so I'm not really complaining 
> too much.  Nevertheless, if this proposal is primarily aimed at realtime 
> communications rather than communications in general, then shouldn't 
> that be reflected in the name?

Well, as a technology project at least initially I think it's 
appropriate to be broadly focused...i.e. looking to produce a framework 
that supports as many communications applications as possible.  OTOH, if 
we find that only realtime communications applications developers are 
getting value from ECF (or the reverse), or that the ECF apis are a 
'force fit' for certain protocols and applications then I think clearly 
we should reduce our scope.

Thanks,

Scott


> jfp
>
> Scott Lewis wrote:
>
> > Greetings Folks,
> >
> > FYI...in response to community feedback, this project proposal has
> >
> > 1) A new name:  'Eclipse Communications Framework' (ECF)
> > 2) A revised proposal:
> >
> > http://www.eclipse.org/proposals/ecomm/index.html
> >
> > We think that this revision adds some detail and provides more 
> > clearly-articulated focus for the project.
> >
> > Please let us know what you think.
> >
> > Thanksinadvance,
> >
> > Scott