incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kay Schenk <kay.sch...@gmail.com>
Subject Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
Date Wed, 16 May 2012 19:58:22 GMT


On 05/16/2012 12:48 PM, Oliver-Rainer Wittmann wrote:
> 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.

well, I'll try it again...I have several versions to play with...I seem 
to recall I had to manually delete the pkgfmt business and then I got it 
to work.

I'll get back to you on this later today.


I think I will make a discussion thread to totally ditch the pkgfmt 
business from Linux update URLs. It would considerably simplify our lives.

>
>>
>> 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.

-- 
------------------------------------------------------------------------
MzK

"Well, life has a funny way of sneaking up on you
  And life has a funny way of helping you out
  Helping you out."
                             -- "Ironic", Alanis Morissette

Mime
View raw message