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.
