[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] Re: E-intro [Was Efficient downloads]
|
Hi Henrich,
Thanks for jumping in. As for the posting
http://dev.eclipse.org/mhonarc/lists/ecf-dev/msg00847.html, here's my
summary of where things ended up (as of Ganymede). If others have a
different view, please just say so.
[From previous posting]
Let me list features we are looking for (just a brainstorming, no
specification yet):
- multiple protocol support (http/https/ftp/file...)
This is a fundamental aspect of ECF's filetransfer API (multi protocol
support).
- pause/resume using partial content requests (connection can be
closed/reopened before an attempt to resume)
Pause and resume are supported for protocols that support it via
IFileTransferPausable. This is implemented as an adapter off of
IIncomingFileTransfer (providers that do not support it do not expose
this adapter). It is supported for both the URLConnection provider and
httpclient provider for http 1.1.
- resume from a different location (e.g. different mirror)
ECF does not support this directly (because it doesn't support mirrors
directly). In p2 support mirror functionality is exposed by the
download manager and the artifact repository (I believe). Such an
approach (resume to different mirror) can be implemented at this level,
but I don't believe it has been for p2 yet.
- multi threaded download of one artifact from one location (starting at
different content offsets)
ECF supported multi-threaded download of either a whole file or
arbitrary sections of a file (see
IRetrieveFileTransferContainerAdapter.sendRetrieveRequest(IFileID
remoteFileID, IFileRangeSpecification rangeSpecification,
IFileTransferListener transferListener, Map options). Although ECF
supports it, I do not believe it is currently being used in p2's
download manager.
- multi threaded download of one artifact from several locations at the
same time
Same basic answer as above.
- multi threaded download of several artifacts at the same time (using
either single threaded or multi threaded single artifact downloads)
Same basic answer as above.
- retrieving information from special headers (like Content-Disposition)
In the API, we do not currently expose the ability to define special
headers. We do, however, have an 'options' map in the entry point
parameters that would allow special headers to be added.
- detecting URL redirections to final mirrors
Depends upon what is meant by 'detecting'. We do (by default) follow
redirects in general. In this sense we detect and redirect. We don't
(yet) expose further levels of control of redirection.
- detecting approximate user's geographical position
This is currently outside the scope of ECF.
- collecting download statistics (slow/unreliable mirror discovery)
ECF exposes the ability to collect data on transfers (i.e. number of
bytes retrieved for a given URL), so supports such data collection. I
believe that the p2 download manager retains some information about
mirrors (e.g. failure info?) and uses this to determine which mirrors to
select.
- dynamic switching between mirrors in case of slow download
Again, with the current API this would be provided via download manager
logic. I don't think that the download manager does this as yet.
- automatic recovery after connection timeout
Not sure I understand what is meant by automatic recovery here. But
this would also (currently) be provided by the download manager rather
than ECF directly.
- good API for verbose progress bars (ability to create a good UI)
We think that the support for jobs, and filetransfer events/notification
does provide such a capability...and p2 is using it to present file
download progress information. We also have added some API specifically
to support this...e.g.:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=220258
- good API for statistics processing
ECF has not done much with this yet...the intention would be to add more
adapter interfaces (e.g. IDownloadDetails or some such) that would be
exposed by implementing providers via an adapter off of
IRetrieveFileTransfer instances.
- configurable behavior (enable configuring features described above)
Most of the ones that ECF supports directly are appropriately configurable.
- ...and perhaps many more (?)
FWIW, here are some of the other things in file transfer added (or to be
added/fixed) via input between the time of the original posting and the
Ganymede release:
https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&classification=Technology&product=ECF&component=ecf.filetransfer&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=CLOSED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=
Thanks,
Scott
Henrich Kraemer wrote:
I just subscribed to the mailing list and I don't know whether I can
reply to a previous post that I have not received.
I am interested in robust and efficient downloading capabilities. Last
year in May an interesting post was made about 'efficient downloads'.
See http://dev.eclipse.org/mhonarc/lists/ecf-dev/msg00847.html
But the thread ends soon after. Did this effort come to some kind of
closure?
Thanks,
Henrich
------------------------------------------------------------------------
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
