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 Mon, 21 May 2012 11:43:05 GMT
Hi Roberto,

On 18.05.2012 19:14, Roberto Galoppini wrote:
> On Wed, May 16, 2012 at 9:26 PM, Rob Weir<robweir@apache.org>  wrote:
>
>> 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).
>>
>
> Is this what we plan to do for OOo 3.3 users too?
>

For OOo 3.3 I have made an own proposal - please have a look at thread "[UPDATE 
SERVICE] proposal a OOo 3.3 update service"


Best regards, Oliver.


>
>>
>> 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.
>>
>
> In this case we might be serving those downloads too.  Considered the
> amount of potential users, we'd like to sort out plan as we did for AOO
> 3.4, so that we can watch traffic and mirror stability.
>
>

Mime
View raw message