incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jürgen Schmidt <>
Subject Re: Extensions and templates
Date Wed, 30 Nov 2011 09:20:23 GMT
On 11/29/11 5:06 PM, Rob Weir wrote:
> On Tue, Nov 29, 2011 at 8:51 AM, Gavin McDonald<>  wrote:
>>> -----Original Message-----
>>> From: Rob Weir []
>>> Sent: Tuesday, 29 November 2011 10:15 PM
>>> To:
>>> Subject: Re: Business models that will not work [was: Re: Can we update our
>>> migration status table?]
>>> On Mon, Nov 28, 2011 at 10:09 PM, Pedro Giffuni<>  wrote:
>>>> FWIW;
>>>> I think a central site for hosting AOO extensions would be welcome. It
>>>> would be fine to have such a site sponsored by donations and web
>>>> publicity, and offering a share of technical support and commercial
>>>> extensions would be fine too.
>>> Compare, for example, Apache Maven with Sonatype's Maven Central.
>>> This is similar to AOO and Extensions.
>> I haven’t really read this thread, but I have a server here in AU if there really
>> nowhere else to host this stuff. Are there any specs on what's required?
>> Or, shoot me if I got the wrong end of the stick.
> Yes, that is the wrong end of the stick.  But it is an interesting
> side of the stick as well, so I'll move it to its own thread, so we
> can explore the options.
> We currently have an extensions repository and a template repository,
> kindly hosted by OSUOSL ( on our subdomains:
> These repositories carry 3rd extensions and templates under a wide
> variety of licenses, including a mix of open source licenses, copyleft
> and non-copyleft, as well as non-open source licensed "freeware" and
> "trial-ware" packages.  Because of these various licenses, I think it
> is unlikely to be something that we could host at Apache, even in just
> binary form.
> So what are our options?
> ==Option 1: Remain at OSUOSL==
> We could remain with OSUOSL hosting.  However, the existing site is
> very unstable.  For this approach to be practical we'd need a
> volunteer with Drupal skills to work with OSUOSL to diagnose what is
> wrong and to restore stability to these services.  Maybe some sight
> maintenance, upgrades or tuning is sufficient?
> I think this would be the ideal short-term solution at the very least.
> ==Option 2: Move Critical extensions to stable host==
> This is more a back up plan if nothing else works in the AOO 3.4
> timeframe.  There are a handful of critical extensions that many users
> will want access to, such as spell checking dictionaries.  If OSUOSL
> is not stable when 3.4 is released, then we will have many thousands
> of very frustrated users.  So with this option we copy the critical
> extensions to Apache-Extras and point 3.4 users to that.
> ==Option 3: Clone OSUOSL repositories to another host==
> In this option we rehost the existing repositories at another host.
> So similar to Option 1, we would need a volunteer with Drupal
> expertise.
> ==Option 4: Host repositories elsewhere, using new UI==
> SourceForge, etc.  There are ways, for example, to create
> meta-communities ("Neighborhoods") at SourceForge across projects.
> Similar things can be done at Google Code or elsewhere.  Take
> advantage of these forges rather than maintaining our own customized
> app.
> ==Option 5: Re-architect the Repositories==
> This is the option I personally favor for long term.  The downside of
> what we have today is we have a single repository with a single host.
> This is non-optimal for several reasons.  There are different needs
> out there if we look at downstream consumers and/or enterprise users.
> They may want to have a restricted or supplemental repository.  I may
> want to make available to my users an interface that shows only
> non-proprietary extensions, plus non copyleft templates plus my own
> proprietary house templates.  Someone else might want to restrict
> things differently.  Look at analogous things with Ubuntu component
> repositories, with the ability to disable or enable proprietary
> drivers and/or non-supported components.
> In a new design we could start up front with a specification for a
> data model for an extension, something expressed in simple XML, with a
> query/fetch interface as a RESTful service.  This would allow multiple
> repositories to look and behave identically from the data perspective.
>   That then allows websites that aggregate such repository data, as
> well as in-app browsers for extensions and templates.  Then you can
> imagine AOO allowing a user or admin to enable any from a list of
> several extension repositories to work with.
> 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.
> (There might be some hybrid way of doing this as well, by using
> SourceForge or similar for the underlying hosting, but then with tags
> or a common extension.xml in the root of each repository, then
> publishing data that we create our catalog from)

today we have one default repository but each extensions can carry it's 
own update Url. That means in detail

- no update Url in the extension package, the default Url is used to 
search for update information for this extension

- update Url in the package, this one is used to search for update 

Such an update Url can link to a simple xml file providing the 
extensions meta data about available updates. This file can of course 
provide information about more than one extension.

Based on this we can probably improve the whole extension management a 
lot. And with some extra work we can provide a filtering and configuring 
mechanism that you probably have in mind.

We should keep in mind that we do also some virus check (as far as i 
know) for the extensions hosted on the OSUOSL repo.

Independent which way we prefer in the future, but we should ensure that 
we have some control over the submitted extensions. I don't know how 
exactly this can be ensured. I think about something like a review 
process, or certifying. Simply to ensure that at least in an official 
repo we don't have any malware.


>> (Happy to do the migration too if that’s needed)
>> Gav...

View raw message