[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] Efficient downloads
|
Hi Thomas,
Thomas Hallgren wrote:
I'm looking for ways to improve Buckminsters download capabilities and
I have some questions regarding the ECF filetransfer provider. As you
might tell by my questions, I'm fairly new to the whole thing :-)
What is the current status for implementations (http, ftp, and
bittorrent in particular)?
We use apache httpclient 3.0.1 for implementing http/https support, the
jre URLConnection impl for ftp, and we have a working EPL bittorrent
implementation (created by committer Remy Suen as part of the Google SOC
project 2006). The URLConnection impl also supports file and jar URLs
(of course). These are all for file retrieval of course...I assume this
is the use case you are interested in (rather than peer-to-peer file
sending which the ECF file transfer API also supports). The top-level
container adapter for file retrieval is:
IRetrieveFileTransferContainerAdapter[1].
Is it possible to resume a download from a certain position (e.g.
using the http Range header attribute)?
We have an adapter interface called IFileTransferPausable, which exposes
semantics for pausing/resuming a file transfer. This is currently
implemented (with the protocols listed above except for bittorrent) via
the Job.sleep() and Job.wakeUp() methods. It doesn't have to be
implemented this way for a given protocol (i.e. it could use protocol
specific mechanisms where available), but we haven't done that yet.
Does ECF provide any resume or recovery after failure capabilities
out-of-the-box?
Resume, yes via IFileTransferPausable adapter. The adapter is
optionally implemented by a given provider implementation.
Recovery from failure...no.
Do you have any abstractions for this?
How much overhead does ECF add in terms of size in a headless
environment assuming an eclipse runtime is active already?
It depends upon which ECF plugins are used. If you are using just the
file transfer api and impls then the filetransfer API bundle (jar) is
currently ~25k and it depends upon the ECF core API (61k), and the ECF
identity API (39k). For file transfer, these are small by comparison
with the size of the apache httpclient implementation bundle (from
Orbit...~290kb).
Just FYI, we went to some significant trouble to reduce the dependencies
of the ECF core APIs to the bare minimum and make them as small as
possible, meaning that for all of these (filetransfer API, core API,
identity API) they require only the CDC 1.0/Foundation 1.0 runtime + the
equinox jobs bundle.
Unfortunately, I don't yet have detailed numbers of memory usage by
bundle...or for the runtime behavior of httpclient under various load
conditions separate from other analyses that people have done of
httpclient (I haven't searched to find these, but I imagine they do
exist...if you find them please make them known to us).
Also...FYI, here's some new subsystem-level docs on ECF that might prove
useful:
http://wiki.eclipse.org/index.php/ECF_API_Docs
There's also some pointers on those pages to test code for filetransfer.
Let us know if we can be of more help.
Scott
[1]
http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/eclipse/ecf/filetransfer/IRetrieveFileTransferContainerAdapter.html
Regards,
Thomas Hallgren
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
