Re: [equinox-dev] [prov] ECF in P2, was request handler orientation

[Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx>]

In scenarios where size matters, or where only one well-known transport is
to be used, the handler give us the ability to remove our dependency on
ECF.
So to me, to know whether or not the handler should be kept, we have to
answer the following questions:

* Size
- Is ECF small enough for scenarios where size matters?
- Can the removal of the dependency on ECF be achieved by another way (for
example having a new DownloadManager)?

* Pluggability
- Can any transport be plugged into ECF, if not what is missing from the
API?
- How more complex would the handler have to become, which other
infrastructure would we have to have when ECF is not present (e.g. how do
we know which transports are supported)?
- How complex is it to plug a new transport?

* Functionality
- What does ECF brings us?
- Will ECF be able to overcome its current limitations? Is the ECF team
aware of these?

Can any one take a look at this?

Thx

PaScaL


|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Stefan Liebig <Stefan.Liebig@xxxxxxxxxxxx>                                                                                                        |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Equinox development mailing list <equinox-dev@xxxxxxxxxxx>                                                                                        |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |08/31/2007 04:03 AM                                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Re: [equinox-dev] [prov] request handler orientation                                                                                              |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|





The current version of ECFHandler (I know it is an early state) does not
support setting of internet proxies nor does it handle certificates for
trusted communications (client trusts server, server trusts client). I
glimpsed at ECF and I saw that it is possible to set a single proxy but
I didn´t saw something similar to the ProxySelector (JRE 1.5).
Or what about a solution that delivers updates like torrents do? ECF can
do that, but can the current ECFHandler do it?
So my conclusion is that it would be good to have a solution that allow
to define request handlers externally.

Stefan

Jeff McAffer wrote:
>
> looking through the artifact repo code I noticed that the way it is
> now, MirrorRequests get/are given a RequestHandler and then that is
> used to do the actual file transfer.  Is there a usecase that drives
> the repo communication policy to be externally defined?  That is, is
> there a reason that the repository object itself should not decide how
> it is going to talk to the backing store (e.g., server)?  For example,
> MirrorRequest.perform() should just say,
> IArtifactRepository.getArtifact(key | descriptor | whatever) and get
> back a stream that it can write into the destination repo.
>
> Thoughts?
>
> Jeff
> ------------------------------------------------------------------------
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev