Hi,

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
http://svn.apache.org/viewvc/incubator/ooo/trunk/main/scp2/source/ooo/common_brand.scp?revision=1296424&view=markup#l1031

${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] 
http://wiki.services.openoffice.org/wiki/Update_Notification_Protocol#A_glance_on_the_code_for_the_Apache_OpenOffice_3.4_release

Regards

Reply via email to