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/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 08/31/2007 11:15 AM Please respond to Equinox development mailing list <[email protected]> To Equinox development mailing list <[email protected]> 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 [EMAIL PROTECTED] 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/[EMAIL PROTECTED] > Sent by: [EMAIL PROTECTED] > 08/31/2007 10:02 AM > > Please respond to > Equinox development mailing list <[email protected]> > > To > > Equinox development mailing list <[email protected]> > > 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 <[EMAIL PROTECTED]> | > > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |------------> > | To: | > |------------> > > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |Equinox development mailing list <[email protected]> | > > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |------------> > | 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 > > [email protected] > > https://dev.eclipse.org/mailman/listinfo/equinox-dev > > > > _______________________________________________ > equinox-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev > > > _______________________________________________ > equinox-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev > _______________________________________________ > equinox-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev _______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
