I'm not going to go back through the process of discussing the merits and downfalls of RSYNC or any other competing protocol or service that might be used as the fetch mechanism. Looking at the draft:
section 3.9.7 "Other access method URIs that reference the same location MAY also be included in the value sequence of this extension. The ordering of URIs in this sequence reflect the subject's relative preferences for access methods, with the first method in the sequence being the most preferred." The last sentence is important, I'll not regurgitate the various discussions I had with the authors to get that in play, instead simply to point out: 1) You need an initial and effective service to code to, and to allow a base common denominator for development and deployment. 2) Where and how you collect the information is by far a secondary concern to the realisation that the information simply needs to exist and at least accessible by 1) So to clarify, you can indeed assert another URI to put in play, and preference it over RSYNC, but still have RSYNC as the lowest common denominator for base level interoperability. Terry On 14/03/2008, at 11:38 PM, Jeffrey Haas wrote: > Florian, > > On Thu, Mar 13, 2008 at 07:59:02PM +0100, Florian Weimer wrote: >> It's not clear to me if you need rsync's capability for transmitting >> collections of files. > > This is the major advantage of using rsync. When you must sync a > large > number of files, it is *very* efficient. > > For our purposes, we just care that we can gather all of the necessary > files. This can be as simple as downloading the latest manifest and > then fetching all changed files within the manifest. This was one of > the reasons I had suggested a "last updated" value for the items in > the > manifest at the microphone at the SIDR meeting. > > -- Jeff > _______________________________________________ > Sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr -- Terry Manderson email: [EMAIL PROTECTED] Network Operations Manager, APNIC sip: [EMAIL PROTECTED] http://www.apnic.net phone: +61 7 3858 3100 _______________________________________________ Sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
