On Mon, May 21, 2012 at 8:01 AM, Oliver-Rainer Wittmann < [email protected]> 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 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<http://people.apache.org/%7Eorw/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 >> <http://www.openoffce.org/?lang=it>requests. I made some test yesterday, >> maybe >> https://issues.apache.org/**jira/browse/INFRA-4624<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. This is good news! I wasn't sure about the "granularity" of something like this... 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 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. > -- ---------------------------------------------------------------------------------------- MzK "The reports of my death are greatly exaggerated." -- Mark Twain
