Hi Pascal,
Pascal Rapicault wrote:
Hi all,
disclaimer: I've never used ECF in
depth.
I may sound a bit old-school and
boring,
but making something API is a commitment and has a strong implication
on
how things can then evolve. Why am I saying that? Because when I
quickly
looked through the code, I only found one internal package, all the
others
are API, is this really expected?
Which plugins/bundles are you referring to? For ECF core and the API
extension plugins (e.g. fileshare, presence, datashare, etc) most of
the interfaces and classes are intended to be external packages. For
the ecf providers (impls bundles) the story is different (much more
internal only).
I also noticed that the filetransfer
package is located in a bundle named fileshare and it requires the
whole
org.eclipse.ecf bundle whereas it should be located in a bundle of its
own (since there is no dependency between the fileshare package and the
filetransfer one) and it only uses 7 classes of o.e.ecf.
In short make sure each
functionality
is split appropriately to maximize reusability without pulling the
whole
world and in general try to use the smallest EE possible.
Yes, filetransfer should/will eventually be in a separate bundle
(rather than in fileshare). Much of the work on filetransfer was just
done, and hasn't had the chance to be moved.
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.
Thanks Pascal for observations,
Scott
|
