Hi Roberto,
On 18.05.2012 19:14, Roberto Galoppini wrote:
On Wed, May 16, 2012 at 9:26 PM, Rob Weir<[email protected]> wrote:
On Wed, May 16, 2012 at 3:16 PM, Oliver-Rainer Wittmann
<[email protected]> wrote:
Hi
On 16.05.2012 20:47, Oliver-Rainer Wittmann wrote:
On 16.05.2012 19:38, Kay Schenk wrote:
On Tue, May 15, 2012 at 11:37 PM, Oliver-Rainer Wittmann<
[email protected]> wrote:
On 15.05.2012 20:45, Oliver-Rainer Wittmann wrote:
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.
I think here some server-side script is needed.
A complete "generic" solution which provides a "static" XML document is
to
hard
figure out.
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.
That is right.
The update functionality searches in the returned XML for its operating
system
and its architecture and a buildid which is greater than its own. If it
does not
found it, it assumes that no newer version is available.
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)
I will do some further checks with the URL query part.
For a "static" solution the URL query part should not be a problem. It
seems
to be completely neglected by the HTTP server.
I have currently some static test XML documents on
http://people.apache.org/~orw/testupdateservice/
The XML documents are included in the HTTP GET response regardless of the
URL query part.
As I am not an expert of HTTP and HTTP server, please correct me, if I am
wrong here.
I'd keep it simple.
Two main tasks:
1) Identify whether there is an update available for the user's current
install
2) Direct the user to that update
I'd keep #2 really really simple. We already know there is an update.
We already have logic on http://download.openoffice.org for finding
the correct download. So for #2 just always send the user to
http://download.openoffice.org.
That approach even does magical things. For example, in the future,
the user might be running OpenOffice on a 64-bit Windows, but they are
running 32-bit OO, since that is all that exists. But when we come
out with a new 64-bit of AOO 3.x, the logic on
http://download.openoffice.org will automatically suggest it. Ditto
for better language support. Someone might be running Spanish AOO 3.4
but then decide to upgrade to Catalan AOO 3.X (assuming it is
available).
Is this what we plan to do for OOo 3.3 users too?
For OOo 3.3 I have made an own proposal - please have a look at thread "[UPDATE
SERVICE] proposal a OOo 3.3 update service"
Best regards, Oliver.
Getting the user to the download site also help us engage them more
with the ecosystem, whether signing up for announcement list,
following us on Twitter, showing how they can get involved in the
project, etc. It is almost always a good idea to send the user to the
website.
In this case we might be serving those downloads too. Considered the
amount of potential users, we'd like to sort out plan as we did for AOO
3.4, so that we can watch traffic and mirror stability.
