User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040616
Hi John,
I'm listening! :-) I've been following the posts in an effort to build a
better picture of the subject matter as well as to validate (or
invalidate) my understanding of the project's goals. I'm not an expert
in group communication or conferencing, so I cannot weigh in on the
nuances of the models you've been discussing (at least not yet).
What I would like this project to deliver is the communication
*infrastructure* that would enable the creation of end-user components
and/or full-featured applications in Eclipse such as those listed in the
proposal. I think the idea is to bring this capability into Eclipse,
specifically, rather than to provide a general abstraction of the domain
(which would of course be beneficial to that goal, but perhaps too
difficult or constraining). I don't think the goal is necessarily to
deliver best-of-breed end-user applications as much as it is to enable
others to do so. However, the reference applications would serve two
important objectives: 1). to validate the API model, and 2). to provide
something useful to the end-user, out-of-the-box.
With the risk of stating the obvious, I believe the approach that has
been so successfully used throughout Eclipse is to have loosely coupled
components with very specific responsibilities play their assigned roles
in order to deliver the overall functionality. This in turn enables
their reuse in a variety of contexts. For this project it would mean, in
my view, capturing the application-level communication primitives -- a
set of concepts and algorithms that commonly occur throughout the domain
-- such as end-points, channels, connections, distributed state,
replication, code migration, locking... whatever makes sense. At a
higher level of abstraction could be conferences, chat rooms,
conversations, participants with identities, etc. Again, all this has to
be relevant in the context of Eclipse; for example, if a plug-in needs
to replicate its state across several instances, it could use the
service without worrying much about how exactly it is done. Once this is
in place, it would (hopefully) enable potential implementors to
contribute new solutions while leveraging existing componentry.
The added challenge that I see here is that some of this may not be
possible by just developing new plug-ins. An example of this is
authentication/authorization. So far, it seems to me that the focus of
the platform's runtime has been squarely on running Eclipse in a
single-user environment. At this time I'm not aware of any mechanism
that would allow the user or a plug-in to restrict/negotiate access to
certain resources and/or functionality (Equinox/OSGI folks, please
correct me if I'm wrong). This specific issue may need to be pushed down
to the underlying platform runtime a-la J2EE. However, I believe
Eclipse's success can be partially attributed to the lean runtime layer
with all functionality delivered via plug-ins, and a departure from that
model may quickly lead to unnecessary bloat and loss of appeal.
I think Scott's notion of using the publish-subscribe, message-oriented
paradigm as the underlying pattern nicely follows existing patterns used
throughout Eclipse -- components interested in events provided by
individual services register themselves with the service and are then
notified of those events via messages. I don't think this necessarily
means that all communication must be done this way. I think it'll be
beneficial to start with Scott's existing work and take the year or so,
as proposed in the milestone schedule, to extend, refactor, and
complement it to everyone's satisfaction.
Thank you for your (and everyone else's) valuable insight. I very much
look forward to participating in this project.