incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver-Rainer Wittmann <>
Subject Re: update service - further information for such a service
Date Thu, 15 Mar 2012 14:18:05 GMT

On 15.03.2012 14:20, Ariel Constenla-Haile wrote:
> Hi Oliver,
> On Thu, Mar 15, 2012 at 12:47:41PM +0100, 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, ...?
> All seems right. One missing point is the query part of the URL,
> a non-WNT feature related to the package format, see
> ${UPDATEURL}?pkgfmt=<pkgformat>
> A web service should analyze the query string, pkgfmt can be rpm or deb
> (in a common Linux install set).

Thanks for the pointer - I will update the wiki.

For a static approach it would mean that we would not have the possibility to 
provide a download link for Linux platforms. In this case we could only provide 
a download website.
For the MacOS X platform we only have <pkgformat>=dmg. Right?
If yes, a static approach could also provide a download link.

Best regards, Oliver.

>> 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]
> Regards

View raw message