On Thu, Mar 15, 2012 at 7:47 AM, Oliver-Rainer Wittmann <orwittm...@googlemail.com> 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] > http://wiki.services.openoffice.org/wiki/Update_Notification_Protocol#A_glance_on_the_code_for_the_Apache_OpenOffice_3.4_release
