Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of apache@robweir.com designates
 69.89.21.8 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1313338531.30865.47.camel@sybil-gnome>
References: 
 <CAP-ksoiPzCqrs2CmSgxvCD1Pz7bFmq04Fueh-WAFBnY4No1UKg@mail.gmail.com>
	<CAA4ffp8G85LW=x9Y++awcrW6TQti2O8goGEJf=367ZH=qxqkSw@mail.gmail.com>
	<8151058839370557907@unknownmsgid>
	<CAA4ffp-+0-bh=zdvGrrkqy4TNcrv2+zUsCscmnh1PXT-=6PTsA@mail.gmail.com>
	<133e716559f67b121374d6f83d310257@tutopia.com>
	<1313324798.30865.16.camel@sybil-gnome>
	<CAP-ksoj50X_dt=30QTtoa=eEPaDcEBZ+RL1ZMgd+sc0k3w6i5Q@mail.gmail.com>
	<4E47CE41.1010306@hdsnet.hu>
	<1313330254.30865.31.camel@sybil-gnome>
	<CAP-ksoj50dJ7HSTUiZ5XJ4B-Sp3EK5gvTQ-TDuk9kSpUs-UboA@mail.gmail.com>
	<20110814151148.GC3585@ulungele.erack.de>
	<1313338531.30865.47.camel@sybil-gnome>
Date: Sun, 14 Aug 2011 12:35:53 -0400
Message-ID: 
 <CAP-ksogo2iR6LxufKqJh7u+LRbPotw6RhO5=Zq6qMLYS8g3aKQ@mail.gmail.com>
Subject: Re: [www] Ext / Temp repository stability ( was Extensions and
 templates site down )
From: Rob Weir <apache@robweir.com>
To: ooo-dev@incubator.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, Aug 14, 2011 at 12:15 PM, drew <drew@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. =C2=A0Is 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. =C2=A0So =
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. =C2=A0They browse a list of extensions, click 'download' a=
nd
>> > they get the extension. =C2=A0But 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. =C2=A0Maybe a simple XML fo=
rmat,
>> > or a web form that generates that XML. =C2=A0Then you need a program t=
o gen
>> > the website from the XML. =C2=A0Xalan 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
>
>>
>> =C2=A0 Eike
>>
>
>
>