incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: update service - further information for such a service
Date Thu, 15 Mar 2012 12:52:15 GMT
On Thu, Mar 15, 2012 at 7:47 AM, 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, ...?

My opinion:

This is an example of a "low rate of change" application.  The data
changes every few weeks or months, not daily or hourly.   It is also a
high traffic service, especially when we have millions of clients
doing automatic update checks.  So a static file is probably better
for server load/performance.

I wonder if the static XML file could be automatically generated via a
script?  Maybe part of our release script?  (I assume we'll eventually
have a release script that deals with cutting RC's, doing the code
signing, etc.)

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

View raw message