incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver-Rainer Wittmann <orwittm...@googlemail.com>
Subject Re: [UPDATE SERVICE] proposal for a AOO 3.4 update service
Date Wed, 16 May 2012 18:47:45 GMT
Hi,

On 16.05.2012 19:38, Kay Schenk wrote:
> On Tue, May 15, 2012 at 11:37 PM, Oliver-Rainer Wittmann<
> orwittmann@googlemail.com>  wrote:
>
>> Hi,
>>
>>
>> On 15.05.2012 20:45, Oliver-Rainer Wittmann wrote:
>>
>>> Hi,
>>>
>>> Am 15.05.12 16:11, schrieb Rob Weir:
>>>
>>>> On Tue, May 15, 2012 at 8:11 AM, Oliver-Rainer Wittmann
>>>> <orwittmann@googlemail.com>  wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>>  From my point of view it would make sense to reactivate a simple update
>>>>> service for AOO 3.4.
>>>>>
>>>>> The update URL for AOO 3.4 is:
>>>>> http://update38.services.**openoffice.org/**ProductUpdateService/check.
>>>>> **Update<http://update38.services.openoffice.org/ProductUpdateService/check.Update>
>>>>> (plus a query part ?pkgfmt=<pkgformat>  for non-Windows platforms)
>>>>>
>>>>> As this URL resolves to nothing, the user currently gets the following
>>>>> response from the update functionality in AOO 3.4:
>>>>> Status: Checking for an update failed.
>>>>> Description: General Internet error has occurred.
>>>>>
>>>>> I propose provide the following XML document when a HTTP GET request
to
>>>>> the
>>>>> above given URL is made:
>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>> <inst:description
>>>>> xmlns:inst="http://**installation.openoffice.org/**description<http://installation.openoffice.org/description>
>>>>> ">
>>>>> </inst:description>
>>>>>
>>>>> Kay already made such an XML document available at:
>>>>> http://www.openoffice.org/**ProductUpdateService/check.**Update<http://www.openoffice.org/ProductUpdateService/check.Update>
>>>>>
>>>>> This response would allow the update functionality in AOO 3.4 to return
>>>>> to
>>>>> the user that the version is up to date.
>>>>>
>>>>> Thus, to reactivate an working update service for AOO 3.4 a redirection
>>>>> is
>>>>> needed.
>>>>>
>>>>>
>>>> Are proposing that we just have a static XML file and redirect the
>>>> requests so it loads that static file?
>>>>
>>>>
>>> Yes, as a short-term and fast solution.
>>>
>>>   I can see that as being a useful short-term solution. But soon we'll
>>>> need some more complicated logic, right? For example, when we enable
>>>> the 3.3. update check, we'll need to know that updates are available
>>>> for some languages, but not others. Can we do that all with
>>>> redirection to static files? Or do we need server-based logic, i.e.,
>>>> a cgi script?
>>>>
>>>>
>>> Static files would be possible, because each version has its own update
>>> service
>>> URL, but it would be not the best solution for the long-term.
>>> Thus, some server-based logic would make sense.
>>>
>>>   If we're going to need a cgi script in the end, I wonder if it makes
>>>> sense to start with one now? We could have a simply script that today
>>>> just always points to the "no update available" XML for AOO 3.4. But
>>>> then we make it more complicated as we go.
>>>>
>>>>
>>> I am currently in preparation of a proposal for an update service for OOo
>>> 3.3
>>> installations. Here, I can/will demonstrate how a server-based logic
>>> would look
>>> like.
>>>
>>>   Can somebody make this happen?
>>>>> I have to admit that do not have the knowledge to do it on my own.
>>>>>
>>>>>
>>>> If we just redirect to a static file, I think you can just enter a
>>>> JIRA request for Infra. If we go with a cgi script then we need
>>>> someone to develop that script first.
>>>>
>>>>
>>> If nobody objects, I would go for this short-term and static approach and
>>> would
>>> ask via JIRA request for Infra, if the redirect to the already existing
>>> static
>>> file can be established.
>>>
>>>
>> I will use issue 119361 - https://issues.apache.org/ooo/**
>> show_bug.cgi?id=119361<https://issues.apache.org/ooo/show_bug.cgi?id=119361>-
to track the progress on this task.
>>
>> Best regards, Oliver.
>>
>
>
> OK, and a very short update on this.
>
> I tried to deal with this and continually ran into issues.
>
> At the simplest, I tired to make up a "generic" update for maybe all
> platforms and languages that would just take them to a page to choose an
> update -- basically our download/other.html at this point.
>

I think here some server-side script is needed.
A complete "generic" solution which provides a "static" XML document is to hard 
figure out.

> However, if you exclude the platform and other particulars in a very simple
> XML file, nothing happens -- in other words, the URL is just ignored and
> you get a "no updates" message. This is what is in:
>   /projects/update36/ProductUpdateService/check.update
> now.

That is right.
The update functionality searches in the returned XML for its operating system 
and its architecture and a buildid which is greater than its own. If it does not 
found it, it assumes that no newer version is available.

>
> Also, life is complicated by appending the "pkgfmt " on update strings in
>
> <AOO install directory>/program/versionrc (for linux...name will vary
> depending on OS)
>

I will do some further checks with the URL query part.

> Finally, whatever we do...assuming we can get a feed to work...under NO
> circumstance should we redirect update30.services.openoffice.org to the
> "dummy" host. The older version 3.0 did something entirely different, and
> when I had infra do this redirect some months ago, it caused the Apache
> webserver complex to crash.
>
> I *thing* the newer services update32, update33, update35, etc. will be
> fine, but we need to verify this.
>

Please let us continue possible update services for former versions in my other 
proposal thread.

Best regards, Oliver.

Mime
View raw message