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... 
Hi Remy and all,

Remy Suen wrote:

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".
If we end up going with splitting the ECF core plugin I would suggest we consider 3 resulting plugins 

identity (namespace extension point):  org.eclipse.ecf.core.identity
container (containerFactory extension point): org.eclipse.ecf.core.container shared object (sharedObjectFactory extension point): org.eclipse.ecf.core.sharedobject
But before we go too much further in these directions...do people really feel this is necessary? That is, do the size reduction benefits (< 136K) obviously outweigh the overhead (addl complexity, more meta files, etc) of having multiple plugins? Perhaps the answer is obviously 'yes', but I just want to explore this a little before we just do it. 




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?
We already are using the IM/presence plugins as both the Eclipse plugins and for the ECF 'rcpchat' application: http://ecf1.osuosl.org. The rcpchat application was done by Ed Burnette in about 4 hours...and he was able to do this by reusing plugins in an RCP context. So the plugins should be reusable in a similar manner for a new RCP app. 




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.


Thanks much Remy.

Scott

Back to the top