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.
