On Tue, May 15, 2012 at 11:37 PM, Oliver-Rainer Wittmann < [email protected]> wrote:
> Hi, > > > On 15.05.2012 20:45, Oliver-Rainer Wittmann wrote: > >> Hi, >> >> Am 15.05.12 16:11, schrieb Rob Weir: >> >>> On Tue, May 15, 2012 at 8:11 AM, Oliver-Rainer Wittmann >>> <[email protected]> wrote: >>> >>>> Hi, >>>> >>>> From my point of view it would make sense to reactivate a simple update >>>> service for AOO 3.4. >>>> >>>> The update URL for AOO 3.4 is: >>>> http://update38.services.**openoffice.org/**ProductUpdateService/check. >>>> **Update<http://update38.services.openoffice.org/ProductUpdateService/check.Update> >>>> (plus a query part ?pkgfmt=<pkgformat> for non-Windows platforms) >>>> >>>> As this URL resolves to nothing, the user currently gets the following >>>> response from the update functionality in AOO 3.4: >>>> Status: Checking for an update failed. >>>> Description: General Internet error has occurred. >>>> >>>> I propose provide the following XML document when a HTTP GET request to >>>> the >>>> above given URL is made: >>>> <?xml version="1.0" encoding="UTF-8"?> >>>> <inst:description >>>> xmlns:inst="http://**installation.openoffice.org/**description<http://installation.openoffice.org/description> >>>> "> >>>> </inst:description> >>>> >>>> Kay already made such an XML document available at: >>>> http://www.openoffice.org/**ProductUpdateService/check.**Update<http://www.openoffice.org/ProductUpdateService/check.Update> >>>> >>>> This response would allow the update functionality in AOO 3.4 to return >>>> to >>>> the user that the version is up to date. >>>> >>>> Thus, to reactivate an working update service for AOO 3.4 a redirection >>>> is >>>> needed. >>>> >>>> >>> Are proposing that we just have a static XML file and redirect the >>> requests so it loads that static file? >>> >>> >> Yes, as a short-term and fast solution. >> >> I can see that as being a useful short-term solution. But soon we'll >>> need some more complicated logic, right? For example, when we enable >>> the 3.3. update check, we'll need to know that updates are available >>> for some languages, but not others. Can we do that all with >>> redirection to static files? Or do we need server-based logic, i.e., >>> a cgi script? >>> >>> >> Static files would be possible, because each version has its own update >> service >> URL, but it would be not the best solution for the long-term. >> Thus, some server-based logic would make sense. >> >> If we're going to need a cgi script in the end, I wonder if it makes >>> sense to start with one now? We could have a simply script that today >>> just always points to the "no update available" XML for AOO 3.4. But >>> then we make it more complicated as we go. >>> >>> >> I am currently in preparation of a proposal for an update service for OOo >> 3.3 >> installations. Here, I can/will demonstrate how a server-based logic >> would look >> like. >> >> Can somebody make this happen? >>>> I have to admit that do not have the knowledge to do it on my own. >>>> >>>> >>> If we just redirect to a static file, I think you can just enter a >>> JIRA request for Infra. If we go with a cgi script then we need >>> someone to develop that script first. >>> >>> >> If nobody objects, I would go for this short-term and static approach and >> would >> ask via JIRA request for Infra, if the redirect to the already existing >> static >> file can be established. >> >> > I will use issue 119361 - https://issues.apache.org/ooo/** > show_bug.cgi?id=119361<https://issues.apache.org/ooo/show_bug.cgi?id=119361>- > to track the progress on this task. > > Best regards, Oliver. > OK, and a very short update on this. I tried to deal with this and continually ran into issues. At the simplest, I tired to make up a "generic" update for maybe all platforms and languages that would just take them to a page to choose an update -- basically our download/other.html at this point. However, if you exclude the platform and other particulars in a very simple XML file, nothing happens -- in other words, the URL is just ignored and you get a "no updates" message. This is what is in: /projects/update36/ProductUpdateService/check.update now. Also, life is complicated by appending the "pkgfmt " on update strings in <AOO install directory>/program/versionrc (for linux...name will vary depending on OS) Finally, whatever we do...assuming we can get a feed to work...under NO circumstance should we redirect update30.services.openoffice.org to the "dummy" host. The older version 3.0 did something entirely different, and when I had infra do this redirect some months ago, it caused the Apache webserver complex to crash. I *thing* the newer services update32, update33, update35, etc. will be fine, but we need to verify this. -- ---------------------------------------------------------------------------------------- MzK "Well, life has a funny way of sneaking up on you And life has a funny way of helping you out Helping you out." -- "Ironic", Alanis Morissette
