[ecf-dev] Two issues I feel that needs a healthy discussion over before

["Remy Suen" <remy.suen@xxxxxxxxx>]

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