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 temporary solution until AOO 3.4 is released.
Date Mon, 19 Mar 2012 16:10:18 GMT
Hi Kay,

On 19.03.2012 17:04, Kay Schenk wrote:
> On Mon, Mar 19, 2012 at 5:00 AM, Oliver-Rainer Wittmann<
> orwittmann@googlemail.com>  wrote:
>
>> Hi
>>
>>
>> On 18.03.2012 22:14, Kay Schenk wrote:
>>
>>> On Sun, Mar 18, 2012 at 10:10 AM, Kay Schenk<kay.schenk@gmail.com>
>>>   wrote:
>>>
>>>
>>>>
>>>> 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.**openoff**ice.org/wiki/Update_**<http://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<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.**ope**noffice.org/****
>>>>> ProductUpdateService/check.**<http://openoffice.org/**ProductUpdateService/check.**>
>>>>> Update<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://**installat**ion.openoffice.org/**<http://installation.openoffice.org/**>
>>>>> description<http://**installation.openoffice.org/**description<http://installation.openoffice.org/description>
>>>>>> ">
>>>>>
>>>>> </inst:description>
>>>>>
>>>>> Can someone implement the redirect?
>>>>>
>>>>>
>>>>   Oliver --
>>>
>>> Hi. I put your snippet out there just a bit ago...and this is what I
>>> currently get as a message from "Check for Updates" in OOo 3.3...
>>>
>>> ++++++++++++++++++++++++++
>>> Staus:
>>> Checking for an update failed.
>>>
>>> Description:
>>> http://update36.services.**openoffice.org/**ProductUpdateService/check.**
>>> Update?pkgfmt=rpmdoes<http://update36.services.openoffice.org/ProductUpdateService/check.Update?pkgfmt=rpmdoes>
>>> not exist.
>>> +++++++++++++++++++++++++++++
>>>
>>> so not exactly what you said but at least OOo doesn't spend time trying to
>>> connect to something that doesn't exist
>>>
>>> ...I have update36.services.openoffice.**org<http://update36.services.openoffice.org>routed
to the web server with
>>> your new snippet in place.
>>>
>>>
>>>
>> Hm...
>>
>> I tested only on Windows with OOo 3.3.0 and OOo 3.1.0 by replace the
>> <UpdateID>  in the file<version.ini>  by a URL to the local file system.
>>
>> Do you have the possibility to try this also with your installation?
>>
>> May be I have overlooked something in the code.
>>
>>
>> Best regards, Oliver.
>>
>
> Oliver--
>
> I am not following here. I have an old binary version of 3.3 installed as a
> normal user would. I do not have a "version.ini" file -- this is part of
> the source not the delivered binary. Users would not be expecting to change
> files associated with the product to deal with this. In other words, we
> need/should come up with a reply that will work with existing installs that
> will not require any other changes.
>
> Am I missing something?
>

it is only for testing XML snippets which would be provided as the response to 
the HTTP GET request.

You should have a <version.*> file in your installation. Under Windows it is 
named <version.ini>. Under Linux and MacOS X it is named <version.rc>.

[ It looks like that I am too much focused on Windows ;-) ]

Best regards, Oliver.

Mime
View raw message