incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kay Schenk <kay.sch...@gmail.com>
Subject Re: update service - proposal for temporary solution until AOO 3.4 is released.
Date Sun, 18 Mar 2012 17:10:13 GMT
On Thu, Mar 15, 2012 at 5:03 AM, Oliver-Rainer Wittmann <
orwittmann@googlemail.com> wrote:

> Hi,
>
> On 15.03.2012 12:47, Oliver-Rainer Wittmann wrote:
>
>> Hi,
>>
>> I have continued the work started by Regina, Ariel and Kay regarding the
>> update
>> service.
>> I have documented my findings at [1].
>>
>> I think we have everything together to bring a corresponding web service
>> back to
>> life.
>>
>> I think we have at least two options for such a web service.
>>
>> If we want to create a 'real' web service which on demand creates an
>> appropriate
>> response the HTTP GET request contains all needed information in its
>> header
>> fields "User-Agent" and "Accept-Language" to implement such a web service.
>> The "User-Agent" field contains the operating system, the machine
>> architecture
>> and the bundled languages of the installed office. If a corresponding
>> installation package of newer version is available a corresponding
>> response can
>> be generated.
>>
>> Another solution could be to provide a static XML document, based on an
>> atom
>> feed, which contains as much entries as installation packages for the
>> latest
>> version are available. For each installation package which defines itself
>> by the
>> operating system, the machine architecture and the bundled languages an
>> entry is
>> needed. Such entries need to be duplicated for every existing office
>> installation with different <UpdateID> in its version.ini.
>>
>> Any thoughts, comments, corrections, ...?
>>
>> BTW, the update service of a certain installed office can be tested
>> locally. No
>> HTTP GET request is involved in this case, but you can test with certain
>> XML
>> documents provided as responses. You can change the value of <UpdateURL>
>> in file
>> <version.ini> of your office installation to a local file URL - e.g. under
>> Windows to something like file:///C:/check.update.xml
>>
>> [1]
>> http://wiki.services.**openoffice.org/wiki/Update_**
>> Notification_Protocol#A_**glance_on_the_code_for_the_**
>> Apache_OpenOffice_3.4_release<http://wiki.services.openoffice.org/wiki/Update_Notification_Protocol#A_glance_on_the_code_for_the_Apache_OpenOffice_3.4_release>
>>
>>
> The <UpdateURL> in the installed OOo 3.3 instances is
> http://update36.services.**openoffice.org/**ProductUpdateService/check.**
> Update<http://update36.services.openoffice.org/ProductUpdateService/check.Update>
> .
> This is no longer available. This also annoys our users I think.
>
> If we can redirect this URL and the redirection would provide the
> following XML document the corresponding update service in these offices
> will reply "<your office> is up to date"
> The XML document which needs to be provided only has to contain this XML
> snippet:
> <?xml version="1.0" encoding="UTF-8"?>
> <inst:description xmlns:inst="http://**installation.openoffice.org/**
> description <http://installation.openoffice.org/description>">
> </inst:description>
>
> Can someone implement the redirect?
> May be http://www.openoffice.org/**ProductUpdateService/check.**Update<http://www.openoffice.org/ProductUpdateService/check.Update>can
be used as the redirect. Here, I think it was Kay, already an XML
> document exists which only needs to be updated.
>
> Note: I have also an OOo 3.1 installed. Here the <UpdateURL> is
> http://update32.services.**openoffice.org/**ProductUpdateService/check.**
> Update<http://update32.services.openoffice.org/ProductUpdateService/check.Update>
> .
> May be we should redirect all URL matching http://update3[0..6].services.*
> *openoffice.org/**ProductUpdateService/check.**Update<http://services.openoffice.org/ProductUpdateService/check.Update>
>

Oliver--

Hi -- I missed this post until just now.

I can put this code snippet in in

http://www.openoffice.org/ProductUpdateService/check.Update
as you suggest.

...and send a note to INFRA regarding the DNS changes

However, I'm a bit concerned with telling users (and perhaps folks using a
very old version) that their version is "up to date" when it isn't.  Is
this all we can do about this right now?


>
>
> Best regards, Oliver.
>



-- 
----------------------------------------------------------------------------------------
MzK

"Follow your bliss."
         -- attributed to Joseph Campbell

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message