incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: [UPDATE SERVICE] proposal for a AOO 3.4 update service
Date Wed, 16 May 2012 19:26:07 GMT
On Wed, May 16, 2012 at 3:16 PM, Oliver-Rainer Wittmann
<orwittmann@googlemail.com> wrote:
> Hi
>
>
> On 16.05.2012 20:47, Oliver-Rainer Wittmann wrote:
>>
>> 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:
>>>>
>>>> On 15.05.2012 20:45, Oliver-Rainer Wittmann wrote:
>>>>>
>>>>> 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.
>>
>
> For a "static" solution the URL query part should not be a problem. It seems
> to be completely neglected by the HTTP server.
> I have currently some static test XML documents on
> http://people.apache.org/~orw/testupdateservice/
> The XML documents are included in the HTTP GET response regardless of the
> URL query part.
> As I am not an expert of HTTP and HTTP server, please correct me, if I am
> wrong here.
>

I'd keep it simple.

Two main tasks:

1) Identify whether there is an update available for the user's current install

2) Direct the user to that update

I'd keep #2 really really simple.  We already know there is an update.
 We already have logic on http://download.openoffice.org for finding
the correct download.  So for #2 just always send the user to
http://download.openoffice.org.

That approach even does magical things.  For example, in the future,
the user might be running OpenOffice on a 64-bit Windows, but they are
running 32-bit OO, since that is all that exists.  But when we come
out with a new 64-bit of AOO 3.x, the logic on
http://download.openoffice.org will automatically suggest it.  Ditto
for better language support. Someone might be running Spanish AOO 3.4
but then decide to upgrade to Catalan AOO 3.X (assuming it is
available).

Getting the user to the download site also help us engage them more
with the ecosystem, whether signing up for announcement list,
following us on Twitter, showing how they can get involved in the
project, etc.  It is almost always a good idea to send the user to the
website.

-Rob

> Best regards, Oliver.

Mime
View raw message