Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Two issues I feel that needs a healthydiscussion overbefore ECF 1.0...


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


Back to the top