incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roberto Galoppini <rgalopp...@geek.net>
Subject Re: [UPDATE SERVICE] proposal for a AOO 3.4 update service
Date Mon, 21 May 2012 16:20:09 GMT
On Mon, May 21, 2012 at 1:43 PM, Oliver-Rainer Wittmann
<orwittmann@googlemail.com> wrote:
> 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.

Thanks Olivier,

 I'm trying to catch up with that thread too, are you working on
making it via the AOO download page or direct downloads?

Roberto

>
>
>
>>
>>>
>>> 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.
>>
>>
>

-- 
====
This e- mail message is intended only for the named recipient(s) above. It 
may contain confidential and privileged information. If you are not the 
intended recipient you are hereby notified that any dissemination, 
distribution or copying of this e-mail and any attachment(s) is strictly 
prohibited. If you have received this e-mail in error, please immediately 
notify the sender by replying to this e-mail and delete the message and any 
attachment(s) from your system. Thank you.


Mime
View raw message