[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] [prov] ECF in P2, was request handler orientation
- From: Scott Lewis <slewis@xxxxxxxxxxxxx>
- Date: Sat, 01 Sep 2007 10:20:12 -0700
- Delivered-to: firstname.lastname@example.org
- User-agent: Thunderbird 22.214.171.124 (Windows/20070728)
Stefan Liebig wrote:
Scott, can ECF detect the internet proxy settings from the operating
system/browser, e.g. on win32 by using the native WinHTTP library?
The current file transfer providers don't, but a new/extended provider
could do this.
But wouldn't it be more effective to use the Eclipse platform proxy
We already have a bug to support this
Scott Lewis wrote:
I admit I'm a little confused by this thread, as it 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 dependency on
So to me, to know whether or not the handler should be kept, we have to
answer the following questions:
- Is ECF small enough for scenarios where size matters?
What would be considered 'small enough'? I know zero bytes of code
is 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 transport...e.g. http).
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
costs (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)?
- Can any transport be plugged into ECF, if not what is missing from
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
provide pluggability/flexibility at the transport level. ECF is
essentially that abstraction.
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
- How complex is it to plug a new transport?
- What does ECF brings us?
...and probably other places.
- Will ECF be able to overcome its current limitations? Is the ECF teamRE: the current (implementation) limitations WRT proxy handling...we
aware of these?
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
handler (ECFHandler as current impl) structure or something else? In
either case, I can probably contribute if that's desired. But I
would like to understand better what the current deficiencies are
(beyond full impl support for proxy handling).
equinox-dev mailing list
equinox-dev mailing list