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
