incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Pescetti <pesce...@openoffice.org>
Subject Re: Extensions and templates
Date Wed, 07 Dec 2011 22:26:33 GMT
On 29/11/2011 Rob Weir wrote:
> ==Option 1: Remain at OSUOSL==
> We could remain with OSUOSL hosting.  However, the existing site is
> very unstable.

This would be best both for short and long term. In the short term, it 
provides continuity of service and it doesn't break existing links. In 
the long term, the Drupal instance can be updated and extended (it's not 
easy, but it is something that would have fairly high chances of 
success) to get it to be something like the new model (distributed 
repositories) you describe in step 5.

An important point that everybody seems to miss is that the instability 
of the current Extensions site 
http://extensions.services.openoffice.org/ is, very likely, unrelated to 
Drupal. The underlying Drupal instance is rather sound (and it perfectly 
managed to sustain the traffic in 2010, which should not be 
significantly different from 2011); from the behavior of the site, it 
definitely seems to me that the instability is due to other components, 
like the caching server (Varnish) in front of it or other caching 
mechanisms.

A second very important point is that we need to get the Extensions and 
Templates source code (two different codebases) under the SGA; while 
Drupal itself is GPL, Thorsten Bosbach while working at Oracle created a 
lot of custom PHP code for the two sites. This code, as far as I know, 
has never been released. Access to the source code is a prerequisite for 
any possible analysis/improvement of the website.

> ==Option 2: Move Critical extensions to stable host==

Indeed, as you write, this would be an extreme option.

> ==Option 3: Clone OSUOSL repositories to another host==

This is not significantly different from Option 1; i.e., if there are 
other hosting options available the mere cloning of the site would not 
take long, but again the problem is not with the site but with caching.

Note that, since the Templates site has already been ported to Drupal 6 
using the so called "code-driven development" technique, that source 
code would allow to install an empty pre-configured clone of the 
Templates site anywhere. This would be extremely useful for testing.

> ==Option 4: Host repositories elsewhere, using new UI==

As I used to say, everybody who thinks that the Extensions or Templates 
sites can be replaced easily has never tried submitting a template! 
Thorsten did a lot of customization work on the two sites; any 
replacement would provide a largely inferior user experience.

> ==Option 5: Re-architect the Repositories==
> This is the option I personally favor for long term. ...
> This would allow multiple
> repositories to look and behave identically from the data perspective.

This is an interesting long term solution indeed, but I see it feasible 
as a (complex) version of Option 1-3; i.e., we obtain the current 
codebase with the aim of updating it and extending it in this direction.

> The other thing this approach does is separate the extension metadata
> from the actual licensed extension.  If we wanted to have a canonical
> repository of registered extensions, but without actually hosting or
> storing the extensions, then that should be OK.  We're hosting URL's
> to resources.  We're not distributing code.

This would offer some advantages, but I see advantages in offering 
hosting for extensions too. The current Extensions site offers both 
options (host there or externally), but if I recall correctly some 
automatic mechanisms, like autogeneration of the update URL, only work 
if the local hosting is used.

Regards,
   Andrea.

Mime
View raw message