RE: [ecf-dev] Two issues I feel that needs a healthy discussion overbefo

[Philippe Ombredanne <pombredanne@xxxxxxxxx>]

Remy:
> But, just what EE should the core ECF stand at? If you think we should
> stick to 1.4 "for now", just how long is "for now" though?
+1 for using ME as EE, if possible. Beyond the fact that a framework
should impose as minimal depdencies as possible, and the fact that 1.5
is NOT linux distro friendly, it would also make general use of ECF
easier, including possible use for things like provisioning in the
platform.

ME being for sure a better option than 1.4.
Or more precisely to match the Eclipse platform core plugins:
Bundle-RequiredExecutionEnvironment: CDC-1.0/Foundation-1.0,J2SE-1.3
Now that's always a bummer when you code not to have the laest
goodies...
Yet, imho the benefits of wider portability far outweights missing bits
of the latest goodies.

Which point to one important thing: the EE SHOULD always be specified in
the manifest.
That's the case for ECF, yet not the case for the Jxta implementation @
OSUOSL.
And that's valid regardless of the the EE chosen of course.

+1 for refactoring the collab plugin and exposing as an examplary
implementation rather than an example.
The same way the JDT is an examplary -- not an example-- implementation.

Just my +2 cents :-)

-- 
Cheers
Philippe

philippe ombredanne | 1 650 799 0949 | pombredanne at nexb.com 
nexB - Open by Design (tm) - http://www.nexb.com 
http://easyeclipse.org  -  irc://irc.freenode.net/easyeclipse



> -----Original Message-----
> From: ecf-dev-bounces@xxxxxxxxxxx 
> [mailto:ecf-dev-bounces@xxxxxxxxxxx] On Behalf Of Remy Suen
> Sent: Saturday, October 07, 2006 9:27 PM
> To: Eclipse Communication Framework (ECF) developer mailing list.
> Subject: [ecf-dev] Two issues I feel that needs a healthy 
> discussion overbefore ECF 1.0...
> 
> 
> Hi everyone,
> 
> As ECF gets closer and closer to 1.0, an API/"structural" freeze is
> going to be right around the corner. I'm bringing two issues that I
> think we should take a look at before the big one-oh release that I
> feel has a direct affect on potential users and developers.
> 
> -------------------------------------
> 
> >From http://dev.eclipse.org/mhonarc/lists/ecf-dev/msg00353.html
> 
> >  > We could...I almost already did.  ECF already has a class
> >  > representing a 'future' (called AsynchResult) and I was mentally
> >  > toying around with using either that or the java.util.concurrent.
> >  > Future in JRE 1.5 standard (similar to AsynchResult, 
> which is based
> >  > upon Doug Lea's concurrent package before 
> java.util.concurrent) as
> >  > one of the methods of IRemoteService invocation (to go along with
> >  > the methods already there:  synchronous call/return, asynch-with-
> >  > listener, asych, and proxy).
> >
> > Good point.  Personally I avoid 1.5 dependencies if there 
> is a way around
> > it.  Not that I am against 1.5 but it raises the bar on consumption.
> 
> 1.5 is an iffy area and I'm sure everyone understands that. Things
> starts to get more interesting if you'll recall some past experiments
> playing with ECF on eRCP, we have bug #149024
> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=149024) filed to
> confirm execution environments (EEs) in that regard.
> 
> The JXTA provider at OSUOSL's CVS uses generics, we've had a 1.5
> problem in the past with bug #152094
> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=152094), and there's
> also a 1.5 issue with the Yahoo! provider at the moment. It's really
> quite simple, anyone with a 1.4 JRE can just have that project use 1.4
> instead and the error will popup (the fix is simple and obvious as
> well). I haven't had a chance to file a bug to that yet
> lately...though, that is, if I should bother at all, per Scott's
> comment from before, "...I *think* ECF would work with only the ME
> profile...[but] providers have varying runtime requirements."
> (http://dev.eclipse.org/newslists/news.eclipse.technology.ecf/
> msg00505.html).
> This is perfectly fair of course, if a provider uses 1.5 for whatever
> reasons, I don't think that's a problem and we shouldn't be
> restricting our provider contributors, they just need to state the EE
> in the MANIFEST.MF and that'll be that.
> 
> But, just what EE should the core ECF stand at? If you think we should
> stick to 1.4 "for now", just how long is "for now" though?
> 
> -------------------------------------
> 
> On an entirely different topic, has there been any thought to pushing
> up/pulling down (those magical refactoring keywords)
> ChatRoomManagerView and/or the whole "example" plug-in
> org.eclipse.ecf.example.collab? While one could look at it as an
> example collaboration plug-in, it also works as a bare-bones IRC
> client, amongst other things based on what other containers are
> available at runtime. Bug #155391
> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=155391) is a good
> example of the problem and its accompanying newsgroup post (and while
> the additional dep's information has been added, I don't think we
> should kid ourselves in that the problem really is solved. No one
> doing a quick scan of available plug-ins (from the 'CVS Repository
> Exploring' perspective or other) is going to realize that
> org.eclipse.ecf.example.collab is the root of what they need to run
> the ECF IRC client. Of course,
> org.eclipse.ecf.ui.irc/org.eclipse.ecf.provider.irc.ui/whatever would
> be far more appropriate, but things are going to get out of hand
> quickly if we were to do that once we start introducing more
> providers.
> 
> I don't think anyone likes the system that's being employed, but it
> does work. I'm sure we can all agree that ECF is pretty understaffed
> and given the resources, it's just how it is right now. I hope no one
> takes this comment as me trying to attack those that had this setup
> created in the beginning.
> 
> -------------------------------------
> 
> I think these are two issues that we need to reach some kind of
> consensus on before finalizing 1.0. I know we're all volunteers here
> and no one's getting paid to do this work, but at the same time we're
> all on this mailing list because we care about ECF. All comments are
> welcome regardless of whether you're an active contributor (since
> you're the one writing the code) or someone looking into leveraging
> ECF for a future or existing project (since you're the one using the
> code).
> 
> Thanks,
> Regards,
> Rem
> _______________________________________________
> ecf-dev mailing list
> ecf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ecf-dev
>