[news.eclipse.technology.ecomm] Re: questions on the proposal

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi Jeff,

Jeff McAffer wrote:
<stuff deleted>

> > At least:  JMS, JavaGroups, some work by team members, possibly JXTA and 
> > Jabber.  Also extension point-provided support for use of 
> > commercial/proprietary protocols for interoperability with existing 
> > systems...e.g. sametime, aim, others.
>
>
> FWIW, I am currently a fan of XMPP (the IETF standard version of Jabber). 
> It appears to really be gaining a following.  There are a few Java bindings 
> out there.  I've been using Smack (jivesoftware.org) for a bit and find it 
> simple and powerful.  In the end however, open and replaceable seem like the 
> key attributes as no matter what you pick someone will need/want something 
> else. :-)

Yes, indeed.  That's definitely the point...to support all relevant 
protocols.

I downloaded smack and will give a go at using as a group messaging 
transport.  Should be easy to do, based upon cursory examination.

> > > 3. Flexible Security: Identity/Authentication, Encryption, and 
> > > Authorization
> > > T: This is very interesting.  In Equinox we have been trying to get 
> > > security work going for a while but with relatively little success.  It 
> > > seems a critical mass is forming.  We will be very interested in what you 
> > > do in this space.
> >
> > I/we would very much like to remain connected to the Equinox/OSGI work 
> > here. The potential for security 'non-starters' is much greater, of 
> > course, with components that could arrive/install/depart via a real-time 
> > group messaging infrastructure rather than an explicit user install. 
> > Ideally, the 'local' component model and the 'distributed component' model 
> > would have/leverage the same or similar platform-provided security 
> > mechanisms.
>
>
> From the brief comments in the proposal I suspect that your security work 
> and that going on in Equinox will be complementary rather than conflicting. 
> At least to date the Equinox efforts have been looking more at secure Java 
> code (e.g., using Java 2 Security) rather than things like authentication, 
> roles, etc.

Good.   How do we best get connected with what is happening in Equinox 
WRT security discussions, etc?

> > > 4. End-to-end System Scalability
> > > Q: What does this cover?
> >
> > 1) Scalability of all network elements...clients,peers/servers/proxy 
> > servers, etc.  2) Scaling to potentially large numbers of simultaneous 
> > users, 3) with many users all potentially generating a lot of traffic 
> > (e.g. conferencing).  I believe that 1 and 3 are higher priority than 2, 
> > but that's IMHO.
>
>
> Raises an interesting question.  Do you plan on doing any server side work? 

I think some is going to be required.  At least for reference 
implementation.

> If so, what?  If not, short of video or audio streaming, what scenarios do 
> you envision that involve large numbers of simultaneous connections for a 
> client?

Support for presentations and online demonstrations is one area that 
could involve large numbers of simultaneous connections.

<stuff deleted>

> > Yes, this is a good idea.  It should be possible/very doable for us, as 
> > long as we are careful to keep the platform requirements low for the core 
> > communications/messaging frameworks.  I don't think this will be a 
> > problem, actually.  Perhaps we should shoot for Foundation as well...hmmm.
>
>
> In general Foundation is pretty powerful.  And certainly for core/protocol 
> needs it should be sufficient.  If you are in Eclipse land then AWT and 
> Swing are not needed etc.  This of course does not stop people from using 
> more in their applications but states that the middleware (i.e., the Ecomm 
> code) does not force them to.

Yes.  We will take a close look at Foundation right away.  I've got the 
OSGI references, but are there others that would be good to look at 
associated with Equinox?

Thanks Jeff,

Scott


> > This
> >
> > > allows for smaller total download/disk footprint as well as running on 
> > > devices such as handhelds and phones (see the eRCP project for a hint at 
> > > that direction).
> > >
> > > - Is there code available?  Milestone 1 is almost here and it calls for 
> > > APIs and apps to be delivered.
> >
> > There is some candidate code that I/Composent will make available.  I have 
> > developed 3 infrastructure plugins and 1 real-time collaboration 
> > application with Eclipse UIs, and the team will decide how much 
> > rework/redesign/extension to make on these plugins before 
> > redesigning/checking things in for this project.
> >
> > If you are interested in examining this work you can try it out and look 
> > at the APIs/source if you wish.
> >
> > http://composent.com/plugin/
> >
> > Regrettably, the docs are very incomplete, but I'm focusing on ecomm 
> > rather than taking this work forward for Composent...and up until now I've 
> > been the only person working on this code/plugins.
> >
> > Jeff please let me know if you want an online demo.  I'm a regular user of 
> > these 'collaboration projects' and can create a user account just for you 
> > so you don't have to use 'guest' accounts.
> >
> > Also let me know if you would like to get access to the cvs projects for 
> > these plugins.
> >
> >
> > > Sorry for putting all these in one message.  I didn't want to flood the 
> > > group with a mess of separate messages as I suspect others will have a 
> > > similar set after reading the proposal.
> >
> > No problem.  I agree the proposal doesn't (yet) detail things...we're just 
> > getting going.  The opportunity to clarify and receive feedback from 
> > others is very good.  I would like to make this a very open project.
> >
> > Thanks.  Please let me know directly (at slewis@xxxxxxxxxxxxx) if you 
> > would like demos or source access, etc.
> >
> > Scott