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

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

My thinking was that repos that care
to be configurable could allow different handlers to be plugged in.  I
like the handler idea, it is more an question of who picks the handler
and who has/uses it.

Jeff

Pascal Rapicault/Ottawa/IBM@IBMCA
Sent by: equinox-dev-bounces@xxxxxxxxxxx

08/31/2007 11:15 AM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To	Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc
Subject	Re: [equinox-dev] [prov] ECF in P2, was request handler orientation

This design decision had been taken at a time where
the artifact repo
objects were simple catalogs and where the whole management of the download
was done by a another entity (download manager and mirror request).
However recent discussions around the design of artifact repository
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=197644)  seems to give
more
responsibilities to artifact repo objects, thus changing where the choice
of the handler could be made.
A counter point to that approach is that it tights repositories to a
particular handler.

PaScaL

equinox-dev-bounces@xxxxxxxxxxx wrote on 08/31/2007 10:35:00 AM:

>
> My original question was about who has and calls the RequestHandler.
> I am all for abstracting the handler and allowing for pluggability.
> The question really is, shouldn't the local repo object be the one
> to communicate with its backend.  As it is now, the MirrorRequest
> has the handler and dictates how the communication happens.
>
> Jeff
>
>

>
> Pascal Rapicault/Ottawa/IBM@IBMCA
> Sent by: equinox-dev-bounces@xxxxxxxxxxx
> 08/31/2007 10:02 AM
>
> Please respond to
> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
>
> To
>
> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
>
> cc
>
> Subject
>
> Re: [equinox-dev] [prov] ECF in P2, was request handler orientation
>
>
>
>
> 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
>
>
> _______________________________________________
> 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

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