Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Re: [prov] Deltas for delivering updates
I agree with Pascal...I think it's best to keep delta logic out of ECF if possible. 

Identification info could be added to ECF's context (e.g. custom URL with version info or a new adapter, an associated provider implementation, etc), but this would at least imply having protocol support for such meta data...which wouldn't be available for all 'typical' file transfer protocols...e.g. http/https/bittorrent, etc.

Scott

Pascal Rapicault wrote: 
As you correctly identified the separation of responsibility between ECF
and the provisioning code is done as follow:
- ECF is used to do the transports (e.g http, ftp, bittorrent). We
leverage, its API, its transport pluggability (and eventually its ability
to restart downloads).
- The provisioning code (DownloadManager) is responsible to cause the
download of all the requested artifacts using the artifact repos. It will
be responsible for picking the best mirror (hopefully we can reuse what is
in Maya) and also doing the parallelization.

  
Can/should delta handling be part of ECF - as a kind of smart
    
transport/download handling? Or is delta handling so important to
provisioning that it should be part of provisioning?
Given our usage of ECF, I don't think that ECF has enough context to be
able to handle delta (it would not have the identification information that
you are talking about). Therefore I think the ability to do delta depends
on the repository in which the artifact is being mirrored to and from and
it should be transparent for the download manager. Therefore with the
current code I think the decision or not to use delta can be made in the
MirrorRequest by checking the characteristics of the artifact repositories
at hand, and the actual logic of getting the right delta could be left to
the implementation of the repositories.

It is also important to note that this code did not receive a lot of
attention and anything could be changed.

PaScaL


                                                                           
             "Liebig, Stefan "                                             
             <Stefan.Liebig@co                                             
             mpeople.de>                                                To 
             Sent by:                  <equinox-dev@xxxxxxxxxxx>           
             equinox-dev-bounc                                          cc 
             es@xxxxxxxxxxx                                                
                                                                   Subject 
                                       [equinox-dev] Deltas for delivering 
             07/11/2007 04:49          updates                             
             AM                                                            
                                                                           
                                                                           
             Please respond to                                             
                  Equinox                                                  
                development                                                
               mailing list                                                
             <equinox-dev@ecli                                             
                 pse.org>                                                  
                                                                           
                                                                           




I am currently investigating how the delta stuff (binary deltas) could fit
into the ongoing provisioning work.

When working with deltas there are certain constraints such as:
- when requesting a delta for an artifact it is essential that the request
contains an identification (version, md5, ..) of the artifact that is
already available on the client, so that is possible to regenerate the new
artifact from the old artifact and the delta.
- the client should not rely on the fact that the server(s) can always
respond with a delta. In some way the client needs to have some flexibility
on handling the data (deltas, complete ´files´) which the server can
respond.

Currently provisioning uses ECF to handle the transport and download.
Can/should delta handling be part of ECF - as a kind of smart
transport/download handling? Or is delta handling so important to
provisioning that it should be part of provisioning?

Any thoughts?
_______________________________________________
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

Back to the top