Hi,
On 20.05.2012 12:39, Andrea Pescetti wrote:
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
Yes.
We can try out several options in advance.
I will work on the XML document to get it more or less complete.
Than volunteers can change the Update URL in their installation and see what
happens.
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
I hope so.
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).
ASF infrastructure team just told me that they can establish difference
redirects on different query parts.
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.
For the re-established AOO 3.4 update service - see other thread - the ASF
infrastructure team told me that the server would handle the amount of HTTP GET
requests.
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, I think for former versions - like OOo 3.3 - we can just ignore it.
But, we could not provide direct download link for Linux installations as we can
not figure out which package format is needed.
Thus, I put an URL of a webpage in the XML document for Linux installations
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.
Here, I am able to support whatever is possible this the XML document.
We can provide direct download links or special webpage URLs for each entry in
the XML document. But, as stated above, we can not provide direct download links
for Linux installation from my point of view.
Best regards, Oliver.
