Hi,

On 21.05.2012 15:29, Oliver-Rainer Wittmann wrote:
Hi,

On 21.05.2012 13:55, Oliver-Rainer Wittmann 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
(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";>
</inst:description>

Kay already made such an XML document available at:
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.


Ok, let us drive this issue a little bit more.

For the static and short-term update service for AOO 3.4 I will do the 
following:
- Creation of HTTP resource [1] provided the above given simple XML document

Done.

- Asking ASF Infrastructure via corresponding JIRA issue to redirect HTTP GET
requests for URL [2] (Update URL of AOO 3.4) to URL [2]

Done - https://issues.apache.org/jira/browse/INFRA-4830


The infrastructure team was reacting very fast.
The redirect is established.

Thus, please check in your AOO 3.4 installation, if the update functionality returns that your installation is up to date.

Thanks in advance, Oliver


[1] 
http://www.openoffice.org/projects/update38/ProductUpdateService/check.Update
[2] http://update38.services.openoffice.org/ProductUpdateService/check.Update

Reply via email to