Jeff, shall I start to revive the push model? I think I have some
Jeff McAffer wrote:
Thanks for all the comments and info
Scott (and others). First, this thread started with something
unrelated to ECF. I was just interested in whether the call to
happen in the MirrorRequest or somewhere in the ArtifactRepository (or
elsewhere). In the end I think that that has been resolved and the
call will be moved as I restructure some of the code.
As for using ECF, I am all for using
it and so far have not found it to be particularly limiting or limited.
If it were then I expect that we would work with you to understand
how we should use it or to enhance it to suit the requirements. For
example, my recent questions about chaining InputStreams. Given your
advice I am going to revisit the approach I proposed and Stefan
to see if we can flip it around to use OutputStreams and have ECF
data through the pipe rather than having clients *pull* data out of the
pipe. Should be resaonbly straightforward as this is what Stefan
had originally (sorry Stefan :-) Anyway, having said that, depending
on how complex this gets, it may be worth our will to still maintain an
insulating later between p2 and whatever handler technology we are
Your points about potential complexity here are well taken and that
will have to weigh into the consideration.
There is a valid question of whether
or not we expose handlers and ECF in the p2 API. We would do well
to avoid it if possible. Not because there is anything wrong with
ECF rather if we can implement p2 without exposing ECF then it is
simpler as there would likely be less API and fewer concepts. Of
course, that might come at the expense of flexibility... We will
have to see.
Finally, we will certainly take you
up on your offer of assistance in structuring the handler code and
I admit I'm a little confused by this thread, as
seems bring up a
range of issues...some of which are related to ECF functionality and
some of which don't seem (to me) to be directly related to ECF per se
(but rather the provisioning request handlers?).
RE: Stefan's original comments about the ECF proxy handling and
authentication structure...the API supports both proxy and arbitrary
auth mechanisms for whatever protocol/provider implementation is used
for the underlying file transfer (http/ftp/efs/bittorrent/etc). ECF
exposes extension points for adding support for other protocols (e.g.
private ones like a repository-specific protocol).
RE: defining request handlers externally...I think the current version
of ECFHandler (version I looked at few weeks ago anyway) is overly tied
to a *particular* (default) protocol/provider (http via URLConnection).
I think this handler could be abstracted and made pluggable, but I
haven't yet given much thought to how this would be done as I'm not yet
familiar enough with all the provisioning code to understand the
external API requirements on request handlers.
Pascal Rapicault wrote:
> In scenarios where size matters, or where only one well-known
> to be used, the handler give us the ability to remove our
> So to me, to know whether or not the handler should be kept, we
> answer the following questions:
> * Size
> - Is ECF small enough for scenarios where size matters?
What would be considered 'small enough'? I know zero bytes of code
best :), but that seems a little 'severe'. Of course ECF's pluggable
transport nature could be sacrificed and a return to the JRE-provided
URLConnection could be used instead, but this returns things to the
state prior to the equinox provisioning work (i.e. bound to a specific
I guess I'm not clear on what benefit removing the dependency on ECF
would have other than a fairly small change in code size, and it's
(return to lack of flexibility in transports) would be pretty clear.
Besides, what's the problem?
> - Can the removal of the dependency on ECF be achieved by another
> example having a new DownloadManager)?
> * Pluggability
> - Can any transport be plugged into ECF, if not what is missing
This is a very important question. I would assert than any file
transfer protocol of interest can be plugged into the ECF filetransfer
API...but if this turns out to be wrong for some transport and API
changes (as opposed to additions) are needed, then I would like to know
about that as soon as possible.
> - How more complex would the handler have to become, which other
> infrastructure would we have to have when ECF is not present (e.g.
> we know which transports are supported)?
I would guess that the handler would have to become significantly more
complex without ECF, because if multiple/pluggable transports are
desired/required then *some* abstraction has to be introduced to
pluggability/flexibility at the transport level. ECF is essentially
> - How complex is it to plug a new transport?
> * Functionality
> - What does ECF brings us?
I would offer that it provides a consistent API to get pluggable file
transfer protocols, suspendable/resumeable transfers, and other goals
for transport pluggability as described here
...and probably other places.
> - Will ECF be able to overcome its current limitations? Is the ECF
> aware of these?
RE: the current (implementation) limitations WRT proxy handling...we
Beyond these, I'm not exactly clear on what people are suggesting are
the limitations of ECF API or specific protocol implementations. If
there are specific limitations (outside the proxy issues) that I/we
should know about then I would appreciate bug and/or enhancement
requests. We are completely able and willing to address any such
limitations as they are identified.
> Can any one take a look at this?
By take a look at this do you mean looking at
redesigning/reimplementing/generalizing the provisioning request
(ECFHandler as current impl) structure or something else? In either
case, I can probably contribute if that's desired. But I would like
understand better what the current deficiencies are (beyond full impl
support for proxy handling).
equinox-dev mailing list
equinox-dev mailing list