Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of orwittmann@googlemail.com
 designates 209.85.214.47 as permitted sender)
Message-ID: <4FB4048B.6020604@googlemail.com>
Date: Wed, 16 May 2012 21:48:27 +0200
From: Oliver-Rainer Wittmann <orwittmann@googlemail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: ooo-dev@incubator.apache.org
Subject: Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
References: <4FB38E67.7040406@googlemail.com>
 <CAGj3216r-Su6rJSrsY6mP48G42cFJdc12ibQBwoOhpB9x4TXjA@mail.gmail.com>
In-Reply-To: 
 <CAGj3216r-Su6rJSrsY6mP48G42cFJdc12ibQBwoOhpB9x4TXjA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

On 16.05.2012 19:27, Kay Schenk wrote:
> On Wed, May 16, 2012 at 4:24 AM, Oliver-Rainer Wittmann<
> orwittmann@googlemail.com>  wrote:
>
>> Hi,
>>
>> as our release AOO 3.4 is out now for more than a week I think it would
>> make sense to reactivate a simple update service for installed OOo 3.3
>> versions.
>> I have already seen a post on the users mailing list that the update
>> functionality is not working in OOo 3.3. I assume that corresponding posts
>> also exist in the forum.
>>  From my point of view it is time to let our OOo 3.3 users know via the
>> update functionality that we have released AOO 3.4.
>>
>> The update URL for OOo 3.3 is:
>> http://update36.services.**openoffice.org/**ProductUpdateService/check.**
>> Update<http://update36.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 OOo 3.3:
>> Status: Checking for an update failed.
>> Description: Error reading data from the network.
>> Server error message: Could not read status line: An existing connection
>> was forcibly closed by the remote host.
>>
>> There are two solutions:
>>
>> (A) "static" solution:
>> Provide an XML document similar to the one which is attached when an HTTP
>> GET request to the above given URL is made.
>> The attached XML document contains an atom feed according to [1]
>> Currently, it only contains entries for:
>> - German, Windows
>> - German, MacOS X
>> - German, Linux, 32bit
>> - German, Linux, 64bit
>> - English-US, Windows
>> I hope I got the inst:os and inst:arch content right for all the platforms.
>> For Windows and MacOS we could directly provide download links. Thus, the
>> update functionality can download it and install it on corresponding user
>> demand.
>> For Linux we can not distinguish the different needed package formats in
>> this "static" solution - as far as I know. Thus, a landing page can be
>> given here. The update functionality can open it in the user's default
>> browser on corresponding user demand. In the attached XML document I
>> included our AOO 3.4 release announcement page as this landing page - this
>> is only a proposal.
>> The final XML document needs to be extended by entries for all possible
>> combinations. This would mean 4 entries (Windows, MacOS X, Linux 32bit,
>> Linux 64bit) for each language which we had released for AOO 3.4.
>> It would be also be possible to include more combinations for which we
>> have no package. We could create a special landing page for these which
>> state that AOO 3.4 is out and that the user might want to have a look, if
>> one of the provided packages would fit her/his needs.
>>
>> For this solution we need to provide the XML document at the above given
>> URL.
>>
>
> Oliver--
>
> Hi. OK, a dumb question...have you ascertained that this doc actually
> works? That is, have you tested it with some sort of URL redirect?

I am testing with my test XML documents on 
http://people.apache.org/~orw/testupdateservice/
I am not using redirects. Instead I am adjusting my version.ini resp. versionrc 
files.

>
> Right now, we have an area on the web server that could house this...in
>
> /projects/update36/ProductUpdateService
>
> If you overwrite check.Update with this file, and do a local host setup,
> your own /etc/hosts, and redirect update36.services.openoffice.org to
>
> 140.211.11.131
>
> you could test it out
>

I will test it.

> One of the problems we will run into, esp for Linux (I don't know about
> other platforms) is that the user has a appended "pkgfmt" already on the
> update URL, so in my experimenting, the update call failed because an
> acceptable package was not found.

 From my point of view this should not be a problem as it seems that the HTTP 
server neglects the URL query part in such a "static" case.
I am not an expert here, please correct me if I am wrong.

>
> Your analysis about just leading linux folks to the url of a page for an
> update is great, but what to do about the existing information?
>

Sorry, but I do not know what you mean by "what to do about the existing 
information?"

> Anyway, copy your doc over to the web server, setup the redirect, and let
> us know how things go.
>

Yes, I will.

Best regards, Oliver.