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
