incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: [UPDATE SERVICE] dynamic approach [was: Re: [UPDATE SERVICE] activation of update service for OOo 3.1 and OOo 3.1.1]
Date Fri, 03 Aug 2012 11:45:41 GMT
On Fri, Aug 3, 2012 at 6:13 AM, Oliver-Rainer Wittmann
<> wrote:
> Hi,
> On 03.08.2012 10:04, Jürgen Schmidt wrote:
>> On 8/3/12 9:51 AM, Oliver-Rainer Wittmann wrote:
>>> Hi,
>>> On 03.08.2012 09:40, Oliver-Rainer Wittmann wrote:
>>>>> in order to avoid that somebody has missed the stuff ongoing
>>>>> regarding the
>>>>> update service for OOo 3.1 and OOo 3.1.1:
>>>>> In another thread - see [1] - Rob asked for the update service for
>>>>> OOo 3.1 and
>>>>> OOo 3.1.1. Nobody objects so far. But this was somehow hidden in
>>>>> another thread.
>>>>> Thus, I am bringing it up to its own thread.
>>>>> I will start working on this task, if nobody objects.
>>>>> [1]
>>>> No objections so far.
>>>> Thus, I will go ahead.
>>>> First, I will ask Apache Infrastructure to establish the needed
>>>> redirect from
>>>> [2] to [3]. In the meanwhile I will create the corresponding XML
>>>> document for
>>>> this update service. I am planning to activate it after our Apache
>>>> OpenOffice
>>>> (incubating) 3.4.1 release.
>>>> [2]
>>>> [3]
>>> I have submitted JIRA issue INFRA-5112 [1] requesting to establish the
>>> needed redirect. I am asking Apache Infrastructure to establish the
>>> redirect until 2012-08-15 in order to reach out our users of OOo 3.1 and
>>> OOo 3.1.1 instance just in time with our planned AOO 3.4.1 release.
>>> [1]
>> I think we should start thinking about a more flexible dynamic approach.
>> A real web service or script that provides the info on demand and
>> dynamically generated based on the parameters. Means we would have one
>> Url in the future where we can much easier tweak  and extend the
>> underlying data instead of new Urls for new releases.
>> The question is
>> - what is posible with the existing infra structure
>> - who has the knowledge and interest to work on this
>> - ...
>> Any ideas or opinions
> Yes, I agree here with Jürgen.
> That is the reason why I am planning to give a talk on ApacheCon EU about
> the update function in AOO and the Update Service. In this talk I will give
> a deep insight in its purpose and functionality which should be enough input
> for a corresponding volunteer to create a "real" web service for our Update
> Service.
> I also expect to get in contact in person with Apache Infrastructure people
> in order to discuss certain prerequisites and requirements.
> But, we can start the discussion right now and here on the list.
> Thus, anybody who has expertise in creating such a web service and
> volunteers to take over this task can get corresponding information about
> the update function and the corresponding protocol here and at the wiki [1].

The question is:  how dynamic does it need to be?  It is not like the
upgrade options change minute by minute.  These change slowly, at the
pace of our release cycle, so every few months.

Getting a live web service hosted brings with it additional concerns
about security, CPU usage, maintenance, etc.  I wonder if a simpler
solution would be one that works with the model of the CMS, e.g., a
source document that is transformed into the needed XML update docs.

For example, a source document could be a single document that
defines, in some easily readable notation, the upgrade paths.  To make
it easier, it might allow wild cards or defaults for things like
languages and platforms.  For example, a notation like this:

version=<3.4.1; lang=en,fr,,de; upgrade=3.4.1
version=<3.3.0; lang=OTHER; upgrade=3.3.0

This could mean:

1) Define upgrade paths for all versions before AOO3.4.1 in
languagesEnglish, Frenchh, Spanish, Italian and German to upgrade to

2) Define upgrade paths for all other languages using versions before
OOo 3.3.0 to upgrade to OOo 3.3.0

Then we would need a script to generate the appropriate XML files,
using this definition file for input.  My guess is it starts with a
giant matrix of all of the upgrade paths, languages*versions, and
fills out the matrix according to the definitions above, in order.  A
later rule overwrites (dominates) an earlier rule.  Then the XML files
are written according to the final matrix.

This should be able to be hooked into the site logic so when someone
edits the definition file and commits it, the updated upgrade XML is
automatically generated.


> [1]
> Best regards, Oliver.

View raw message