Re: [ecf-dev] Two issues I feel that needs a healthydiscussion overbefor

[Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx>]

Thanks Remy for backing me up on the
split of ecf!
My main driver for minimizing the size
is that there is no good filetransfer API out there (or at least I did
not come across one).
If ECF has a clear, good and stable
API (and also a diverse set of providers), then it could really impose
itself. So where does the minimal dependency comes in? To ease adoption.
The simpler your API is, the easier it is for people to grasp, and also
the more attractive it looks if it is small.

As for the EE, I would strongly encourage
you to look at foundation. It sounds more impressive than it really is
(see this link for instructions http://wiki.eclipse.org/index.php/Execution_Environments).
For background, when we set the EE for the runtime bundles (e.g. registry),
we were actually very surprised by the few changes we had to do because
we were barely using any 1.4 APIs, or the few we had were no brainer to
port to the foundation APIs. 
By making the EE as small as possible you broaden even more the scope of
your potential users (for example, update manager could not use filetransfer
API from ECF if it was not restricted to foundation).

That said, I'm not arguing for having
all the ECF bundles written against foundation, but just the APIs (for
example some filetransfer providers could be relying on 1.4 or others).

PaScaL

"Remy Suen" <remy.suen@xxxxxxxxx>
Sent by: ecf-dev-bounces@xxxxxxxxxxx

10/12/2006 03:46 AM

Please respond to
"Eclipse Communication Framework (ECF) developer mailing list." <ecf-dev@xxxxxxxxxxx>

To	"Eclipse Communication Framework (ECF) developer mailing list." <ecf-dev@xxxxxxxxxxx>
cc
Subject	Re: [ecf-dev] Two issues I feel that needs a healthydiscussion        overbefore ECF 1.0...

Hi everyone,

I'm responding to different threads here since I didn't want to create
multiple mail spam, so things may seem a bit disorganized if you have
not been following from the start.

> > Also find attached an experimental org.eclipse.ecf.filetransfer
bundle. It
> > currently hold a copy of 7 classes from o.e.ecf just to show
how little from
> > o.e.ecf was being used and the EE is set to 1.3 but it could
surely be moved
> > to something smaller like foundation. Note that this reorganization
allowed
> > me to shrink the size of the jars required to use the filetransfer
API from
> > 136K (o.e.ecf 122K + o.e.ecf.fileshare 14k) down to 16Ko (one
bundle) which
> > definitely makes it more interesting...
>
>  Yes...the small size of file transfer is a big advantage...and
it isn't
> dependent upon the (legacy) fileshare.

I think that what Pascal is trying to get at here is that
org.eclipse.ecf.filetransfer only needs seven classes from
org.eclipse.ecf, but org.eclipse.ecf is rather big in and of itself,
which magically balloons the size to 136k when it could technically be
as low as 16k. So I guess the question is how can we split
org.eclipse.ecf some more to maximally downsize the root bundle that
all ECF components depends on. Doing a quick skim in package explorer,
perhaps we could have something like org.eclipse.ecf.core and
org.eclipse.ecf.sharedobject. I think that anymore might be overkill,
although perhaps others thinks otherwise. I'm not too familiar with
the core package, so perhaps that are better ways to perform a "bundle
split".

> 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.
>
> Check out this (fresh) posting from Jeff McAffer (an authority in
the matter
> :-) ) and the related thread for Europa.
> http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg00680.html

I was originally of the opinion that we should stick to 1.4 for as
long as possible (which you can interpret as being "forever"),
but I
see now that there are people out there are quite well off with even
lower requirements and definitely will not be budging anytime soon, if
ever. Unfortunately, my BitTorrent library uses nio, maybe it is time
for a rewrite? ;P

> I think it has been some time since I tried the collab example (IM
and
> IRC), so I should refresh my memory, but personally, I don't think
it
> qualifies as exemplary (yet?). It has some basic minimal
> functionality, but has many issues and the look & feel needs work.

I agree. The L&F is quite awkward and feels rather inconsistent. For
myself, in the case of the IRC window, I find the whole CTabFolder in
CTabFolder rather ugly, especially given the fact they are both
aligned on the top (so it looks like they are stacking but then not
really, and a user could click on the wrong tab, etc...) when you will
recall that the PDE Forms editor uses regular tabs (or maybe they're
CTabItems, but at least they aren't curved) and are at the bottom. I
use a similar approach for my BitTorrent plug-in examples ViewPart,
except that I display the 'X' closing button.

> What about creating an exemplary(!) RCP application (that could also
> run as a perspective in Eclipse) that can function as IM & IRC
(and
> maybe Bulletin Board) client?

I believe we have something like that for the Jabber provider, so I
imagine we can reuse/build on that code. I'm not really an RCP guy
myself so have not really looked at it though. Can anyone familiar
with that client comment on this?

> a) go through a refactoring to extract out the generic UI and
> connect/login functionality into either the org.eclipse.ecf.ui plugin
> and/or the org.eclipse.ecf.client plugin
> b) Reimplement/refactor the collab client as plugin(s) for Eclipse-based
> usage
> c) Create a new RCP application that uses plugins from 'a' and 'b'

The general code of A can probably be fed back to eRCP for bug #149375
[1]. B and C sounds like a good direction to take to me. Anyway, I
have opened up bug #160633 for this [2] per Scott's suggestion.

> (I should also remove the Java 5 stuff from the bulletin board API)

Erkki, please make a comment on your bug [3] when you've taken care of
that. :)

Regards,
Rem

[1] [eRCP] UI for ECF - https://bugs.eclipse.org/bugs/show_bug.cgi?id=149375
[2] org.eclipse.ecf.example.collab needs to be refactored into usable
exemplary implementations -
https://bugs.eclipse.org/bugs/show_bug.cgi?id=160633
[3] [Provider] Bulletin Board API -
https://bugs.eclipse.org/bugs/show_bug.cgi?id=150756
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev