Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of rgaloppini@geek.net designates
 74.125.149.141 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4FBA2A49.8050303@googlemail.com>
References: <4FB247E8.3020507@googlemail.com>
	<CAP-ksoicP8evJxtzSL1KVibR_qJP8NsbUKemRf2hqhsMBuRTWA@mail.gmail.com>
	<4FB2A466.1030100@googlemail.com>
	<4FB34B1F.3030105@googlemail.com>
	<CAGj3217G7cTUG44LM1YXjZ_YMNFEDzRYR79Ch3grESKBpec_Kw@mail.gmail.com>
	<4FB3F651.2060300@googlemail.com>
	<4FB3FD19.8040703@googlemail.com>
	<CAP-ksoh6Nqey3FHz7BciqH8NdgEzEtNTTGud5vhYLF5Z6boyvg@mail.gmail.com>
	<CACm2uJib4t1yngKLbN=AJhC-Bw1gJH1umGD8FEyuj-KhiwFF5Q@mail.gmail.com>
	<4FBA2A49.8050303@googlemail.com>
Date: Mon, 21 May 2012 18:20:09 +0200
Message-ID: 
 <CACm2uJiTWPEeoEMmrUmBF=FYYPJ-UMeHc=V=6n53TCwvfSojug@mail.gmail.com>
Subject: Re: [UPDATE SERVICE] proposal for a AOO 3.4 update service
From: Roberto Galoppini <rgaloppini@geek.net>
To: ooo-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, May 21, 2012 at 1:43 PM, Oliver-Rainer Wittmann
<orwittmann@googlemail.com> wrote:
> Hi Roberto,
>
>
> On 18.05.2012 19:14, Roberto Galoppini wrote:
>>
>> On Wed, May 16, 2012 at 9:26 PM, Rob Weir<robweir@apache.org> =A0wrote:
>>
>>> On Wed, May 16, 2012 at 3:16 PM, Oliver-Rainer Wittmann
>>> <orwittmann@googlemail.com> =A0wrote:
>>>>
>>>> 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<
>>>>>> orwittmann@googlemail.com> =A0wrote:
>>>>>>>
>>>>>>>
>>>>>>> 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
>>>>>>>>> <orwittmann@googlemail.com> =A0wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> =A0From my point of view it would make sense to reactivate a sim=
ple
>>>>>>>>>> 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.Upda=
te>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> (plus a query part ?pkgfmt=3D<pkgformat> =A0for non-Windows plat=
forms)
>>>>>>>>>>
>>>>>>>>>> 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=3D"1.0" encoding=3D"UTF-8"?>
>>>>>>>>>> <inst:description
>>>>>>>>>>
>>>>>>>>>> xmlns:inst=3D"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 th=
e
>>>>>>>>> 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 mak=
es
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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 log=
ic
>>>>>>>> would look
>>>>>>>> like.
>>>>>>>>
>>>>>>>> Can somebody make this happen?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I have to admit that do not have the knowledge to do it on my ow=
n.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> 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=3D119361<
>>>
>>> https://issues.apache.org/ooo/show_bug.cgi?id=3D119361>-
>>>>>>>
>>>>>>> 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 choos=
e
>>>
>>> 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 operati=
ng
>>>>> 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 strin=
gs
>>>
>>> in
>>>>>>
>>>>>>
>>>>>> <AOO install directory>/program/versionrc (for linux...name will var=
y
>>>>>> 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. =A0We already know there is an update=
.
>>> =A0We already have logic on http://download.openoffice.org for finding
>>> the correct download. =A0So for #2 just always send the user to
>>> http://download.openoffice.org.
>>>
>>> That approach even does magical things. =A0For 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. =A0But when we come
>>> out with a new 64-bit of AOO 3.x, the logic on
>>> http://download.openoffice.org will automatically suggest it. =A0Ditto
>>> 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.

Thanks Olivier,

 I'm trying to catch up with that thread too, are you working on
making it via the AOO download page or direct downloads?

Roberto

>
>
>
>>
>>>
>>> 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. =A0It is almost always a good idea to send the user to th=
e
>>> website.
>>>
>>
>> In this case we might be serving those downloads too. =A0Considered 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.
>>
>>
>

--=20
=3D=3D=3D=3D
This e- mail message is intended only for the named recipient(s) above. It=
=20
may contain confidential and privileged information. If you are not the=20
intended recipient you are hereby notified that any dissemination,=20
distribution or copying of this e-mail and any attachment(s) is strictly=20
prohibited. If you have received this e-mail in error, please immediately=
=20
notify the sender by replying to this e-mail and delete the message and any=
=20
attachment(s) from your system. Thank you.