Re: Proposal for a centralized Eclipse update manager site for Apache projects/software
On Tue, 3 May 2005, Jeffrey Liu wrote: I want to propose a centralized Eclipse update manager site for Apache projects/software. Reason I propose an Eclipse update manager site for Would be excelent if it can be tied up with the existing dist/mirrored infrastructure for anything 'bulk' downloads. So I guess this boils down to - Lets make absolutely shure that the actual jar/tar/zip's are fetched from the mirred repo's. - what extra metadata should be added to the repository or somewhere else. And who maintains this. - which crowd writes and maintains the clever code which takes this data and populates the Eclipse update site. In the ideal case it would extract the extra metadata from the jar/tar so it can also be used by other similar update managers (or external things like maven). Dw
RE: Proposals
On Fri, 7 Nov 2003 [EMAIL PROTECTED] wrote: not as much bandwidth... So lets design this a bit better then = make sure that it allows for the authoritative source to be on ASF[*] hardware (perhaps with an ASF signed key, sha1 or md5) - but it can be mirrored out through ibiblio, my local disk, or wherever - without compromsing trust, oversight, etc. If that means we need to maintain a 'master' list of checksums or something else signed on trusted hardware - that can be arranged. Either as a web page or through some clever DNS/urn naptr mechanism. But there is no reason not to decouple the trust/authoritative chain and/or metadata from the actual bulk payload. Dw *: or whoever else is authoritative on the package.
RE: What does the repository enable?
one of the issues with the descriptor approach is bandwidth. This very much depends. Yes - it is overhead (which may be small when well designed) - it may need superfluous TCP opens (when not too well designed) - but it also opens up a whole new set of optimizations, of efficient caching, of trust management, of (partial) mirrors and more ways of avoiding fetching the wrong file as entropy does its usual (and unavoidable) think. So I think that in the long run this trade off may actually be on the bandwidth (or at least perceived latency) side of the coin. Dw
