On Sun, Aug 14, 2011 at 12:15 PM, drew <d...@baseanswers.com> wrote: > 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]. >
If there are "standard extensions", where we store the source in SVN, treat it as part of the project and release via the normal procedures, then I can certainly see hosting the extension on Apache servers. But I don't see that happening for 3rd party extensions. I don't think the basic situation changes based on domain names openoffice.org versus openoffice.apache.org. If it is on Apache servers, controlled by the Apache project, using the Apache trademarks, then it is hard to say that code distribution can be done without following Apache rules for releases and licensing. Aside from the licensing concern, I'd also be concerned with the impact of hosting commercial (non-open source) extensions on our status as a non-profit. I think we have a two workable solutions: 1) Host all of the extensions externally. This could include Apache-extra.org. We could link to such an external repository from our website, with a suitable disclaimer stating that this is a non-Apache site. 2) Host only the description and metadata, essentially a catalog or directory, and require that all non-Apache owned (not in our SVN) extensions be hosted externally. This could include external hosting at Apache-extras,org, SourceForge, Google, or whatever else the author prefers. Either option would obviously require some coordination and communications with the extension authors. I prefer option #2. Another thing to consider is this: If there is some load related issues here, then we should consider taking a close look at the top 5 or so extensions and see if we can get them, or equivalent features into the core AOOo release. So better than dealing with load, we can prevent the requests altogether by giving users what they want in the core release. > Thanks > > //drew > >> >> Eike >> > > >
