incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Pescetti <pesce...@apache.org>
Subject Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
Date Sun, 20 May 2012 10:39:59 GMT
On 18/05/2012 Oliver-Rainer Wittmann wrote:
> Thus, please let me in more detail describe what I am observing:
> For the "static" solution we would have a corresponding HTTP resource
> (our XML document) at URL X. I see that the HTTP GET requests made by
> the update functionality in AOO 3.4 and OOo 3.3 to URL X?pkgformat=deb
> are answered by the HTTP server. The response from the HTTP server
> contains the requested HTTP resource - in our case the XML document.

OK, so if I understand properly:
- We can serve the same XML file to all OpenOffice.org 3.3 installations
- Each OpenOffice.org 3.3 installation will parse the file and find out 
whether updates are available or not
- inst_id as in http://people.apache.org/~orw/testupdateservice/33 
contains the language, so this can be exploited too
- Updates can be served as download files or web pages

This is very good since it would allow to:
- Properly cache the XML file to avoid excessive traffic
- Languages not covered by OpenOffice 3.4 can be set not to display 
updates for the time being (e.g., the "fi" version won't report that 
updates are available until 3.4.1, which will include "fi", is released)
- We can take advantage of redirecting to a (possibly localized, since 
we can take advantage of it) URL and we can delegate information 
provision and download logic to it

> If, I understand your observations correct, you need to remove the query
> part from the update URL in order to assure that the update
> functionality recieves the XML document. Is this correct?

This is basically the same problem as handling the 
http://www.openoffce.org/?lang=it requests. I made some test yesterday, 
maybe https://issues.apache.org/jira/browse/INFRA-4624 can be useful 
(mod_rewrite handles the query fragment in a special way).

I would definitely suggest to use a separate machine to serve that 
traffic, unless we are really sure that the www.openoffice.org web 
server won't suffer from it.

> The HTTP GET request contains information about the installed version
> making the request. The needed package format is currently "coded" as
> the URL query part. But, it could be also "coded" in the HTTP
> "User-Agent" field.

OK, but we can completely ignore/reset it right? I.e., the problem could 
be solved by providing a generic XML file and delegating to 
OpenOffice.org 3.3 all handling.

> Yes, we should wait for at least one week to establish the update
> service for OOo 3.3. And then only for OOo 3.3

OK, and here comes the issue of serving them through MirrorBrain or not 
(when we believed that the only way to distribute updates was unassisted 
downloads, there was some consensus on using MirrorBrain for updates). 
On one hand, as I wrote, I consider MirrorBrain an important community 
resource and I hope that they are available to help this project too, 
and that it is possible to identify a role for them in the current 
setup. On the other hand, SourceForge so far worked quite well... The 
good thing is that we can be completely granular, like (just inventing) 
using the nice capabilities of partial local mirroring offered by 
MirrorBrain to distribute non-English updates through its network and 
English updates through SourceForge.

Regards,
   Andrea.

Mime
View raw message