In a distributed system, you also need to deal with security issues and the safety of the download.
It might mean that the directory contains signatures or something that the downloading app can use to validate what it gets from the download URL, especially if we are going to do silent downloads and installs when the user says go get-em. There is probably other attack surface to identify as well. - Dennis -----Original Message----- From: drew [mailto:d...@baseanswers.com] Sent: Sunday, August 14, 2011 09:16 To: ooo-dev@incubator.apache.org Subject: Re: [www] Ext / Temp repository stability ( was Extensions and templates site down ) On Sun, 2011-08-14 at 17:11 +0200, Eike Rathke wrote: > Hi Rob, > > On Sunday, 2011-08-14 10:17:28 -0400, Rob Weir wrote: > > > IIRC, these extensions are 3rd party, under a variety of licenses, > > including some that are not open source. Is that correct? > > Yes. I for one agree with this expansive policy, but understand that personal views of the members here are strong and across the spectrum. Indeed the policy adopted for the TDF repository is a compromise to address the question. > > > Another option, which I brought up the last time this topic was > > discussed on the list, is that we maintain a catalog of extensions, > > but don't maintain the storage of the extensions themselves. So a > > distributed approach where we own the directory. > > Currently OOo has the functionality to query whether an upgrade of the > extension is available and to download and update if so. The directory > then should implement that. Note that it is not necessary to have the > directory provide the extension itself, this is already the case with > the current extension repository that allows to host the extension at > a different place. IIRC some metadata and an URL is sufficient, > hopefully someone familiar with the mechanism can jump in on that. Maybe > Juergen? > > > >From the end-user perspective, they should not notice a big > > difference. They browse a list of extensions, click 'download' and > > they get the extension. But the extension would be served by an > > external site, the responsibility of the extension author. > > > > For this to work we'd need some way for extension authors to submit > > their extension descriptions and metadata. Maybe a simple XML format, > > or a web form that generates that XML. Then you need a program to gen > > the website from the XML. Xalan XSLT could be used for this, for > > example. > > > > What do you think of a distributed approach like this? I have two quantitative questions which I would strongly wish to have answered, if possible, before offering my opinion on long(ish) hosting options. 1 - The percentage of inbound visitors coming from the application vs from search engines. 2 - The percentage of artifacts that are stored directly on the OSUOSL server vs a link to a remote site. I am working on the assumption that this is a very high ratio, where a goodly number of these local files are _likely_ stored only on this server. (not sure there would be anyway to actually answer the last part of that sentence for sure..) > > Fine. Isn't much different from the current situation. Best if technical > details could be worked out such that no code apart from the actual > repository/directory URL needed to be changed. One other thought - I want to restate what I said earlier, regarding what we can (could) do on a server inside the ASF physical custody vs 3rd party maintained servers - I believe I should of based the distinction not on the location of the server, but rather the URL (domain), so that it is significant the difference between [x].openoffice.org and openoffice.apache.org/[x]. Thanks //drew > > Eike >
