incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver-Rainer Wittmann <orwittm...@googlemail.com>
Subject Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
Date Mon, 21 May 2012 15:01:16 GMT
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.

Mime
View raw message