incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kay Schenk <>
Subject Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
Date Mon, 21 May 2012 16:06:47 GMT
On Mon, May 21, 2012 at 8:01 AM, Oliver-Rainer Wittmann <> wrote:

> 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 3.3 installations
>> - Each 3.3 installation will parse the file and find out
>> whether
>> updates are available or not
>> - inst_id as in**testupdateservice/33<>contains
>> 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
>>**lang=it <>requests.
I made some test yesterday, maybe
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.

 This is good news! I wasn't sure about the "granularity" of something like
So, if they can deal with re-routing the "pkgfmt" business, we would be
good for a direct to page. Great!

>  I would definitely suggest to use a separate machine to serve that
>> traffic,
>> unless we are really sure that the 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
>> 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.


"The reports of my death are greatly exaggerated."
                                 -- Mark Twain

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message