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

["John F. Patterson" <john_patterson@xxxxxxxxxx>]

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.

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.

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.  In this case, it might make sense to work through to completion 
on one API before addressing the other.

jfp

Scott Lewis wrote:

> 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