incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver-Rainer Wittmann <>
Subject Re: [UPDATE SERVICE] proposal a OOo 3.3 update service
Date Fri, 18 May 2012 08:09:29 GMT

On 17.05.2012 03:13, Kay Schenk wrote:
> On Wed, May 16, 2012 at 1:44 PM, Oliver-Rainer Wittmann<
>>  wrote:
>> Hi,
>> On 16.05.2012 21:58, Kay Schenk wrote:
>>>>>    [snip]
>>>>   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
>>>>> 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 have recently tested on Ubuntu with an old developer snapshot of AOO 3.4.
>> It just worked fine, even with an update URL having the query part.
> OK...I recall I had to take this off and then it did work with getting me a
> URL page.

I am not sure, if we both about the same.
Thus, please let me in more detail describe what I am observing:
For the "static" solution we would have a corresponding HTTP resource (our XML 
document) at URL X. I see that the HTTP GET requests made by the update 
functionality in AOO 3.4 and OOo 3.3 to URL X?pkgformat=deb are answered by the 
HTTP server. The response from the HTTP server contains the requested HTTP 
resource - in our case the XML document.
Then the XML document is parsed by the update functionality in AOO 3.4 resp. OOo 
3.3. Two cases needs to be distinguish here:
(1) XML document is in the simple form - only containing XML element 
<inst:description> with corresponding childs.
(2) XML document is in the atom feed form

In case (1) the update functionality checks the following three conditions:
(a) <inst:os> content matches the one of the installed version
(b) <inst:arch> content mathes the one of installed version
(c) <inst:buildid> contant - BuildID of newer version - is greater than the 
BuildID of the installed version.
Possible values for <inst:os> and <inst:arch> can be found in [1].
If the conditions hold further information are read - <inst:version> and 
<inst:update> - and the user is presented the information that an update is 
available together with the update URL.
If the conditions do not hold - e.g. empty <inst:description> element the user 
is presented the information that installed version is up to date.

In case (2) the update functionality searches for entries which matches the 
condition that attribute term of element <category> matches the one of installed 
version. Then action as in case (1) are performed on each entry until an entry 
matches the above conditions.

If, I understand your observations correct, you need to remove the query part 
from the update URL in order to assure that the update functionality recieves 
the XML document. Is this correct?


>> When I browse to****
>> ProductUpdateService/check.**Update?pkgformat=deb<>using
the FireFox it provides me the content of the XML document.
>> BTW, I have already updated the XML document as you suggested. As I forgot
>> to include an entry for Linux 32bit in my first try you may be hit my first
>> XML document.
>>   I'll get back to you on this later today.
>> Ok, thanks.
> OK, well since I am at 3.4., I can't help much with this without editing
> the XML doc yo have out there I'm afraid, so I will take your word for what
> you say works and just hope we can get on with things.

Yes. When you are testing with a released AOO 3.4 you at least need to increase 
the value of <inst:buildid> in the XML document to get the information from the 
update functionality that an update is available.

>>> I think I will make a discussion thread to totally ditch the pkgfmt
>>> business
>>> from Linux update URLs. It would considerably simplify our lives.
>> Do you mean for future versions of AOO?
> yes...this would be best I think. Installing on Linux automatically can be
> tricky if you're not root anyway. No harm in just shuttling folks to a page
> to choose something and then do the install in my mind.

I never tried the automatic installation on Linux. I will hae a look in my 
Ubuntu VM which has OOo 3.3 installed.

>> This may be possible, because this information could also "coded" into the
>> "User-Agent" field of the HTTP GET request.
> I don't get your meaning here. Sorry.  ????

The HTTP GET request contains information about the installed version making the 
request. The needed package format is currently "coded" as the URL query part. 
But, it could be also "coded" in the HTTP "User-Agent" field.

> OK, the next step, which we should deal with very cautiously given my past
> experiment, is to get infra to redirect to
> the web server IP address.

 From my point of view we only should redirect the update URL of OOo 3.3 - 
namely update36..... If it works fine, we can think of redirecting further 
update URLs from former versions.
My personal opionion is that such redirects are not needed - but this is only my 

> It would be better if we could just try this with a very limited set of
> updates for the time being...maybe just 32 bit Linux German, for example,
> and take out the others for a bit and see what happens.
> The other thing is since we're still in the midst of the traffic for the
> new release, it would be better to wait at least another week. I know
> you've been after this for a while, and I completely understand, but well,
> results were REALLY disastrous with the update30 re-route -- I kid you not.
> Within 2 hours it incapacitated the Apache web server with the bad "post"
> calls -- I mean ALL of it -- all sites, and the redirect had to be backed
> out. I know we use "get" now and not post, but who would know this?

Yes, we should wait for at least one week to establish the update service for 
OOo 3.3. And then only for OOo 3.3

> Maybe infra has like a different server we could use -- with a web server
> running on it, but not the main server. I'll try to find out tomorrow on
> #asinfra or you could get on there and find out.

That is great that you are getting in contact with ASF infra regarding this 
issue. Thx.

Best regards, Oliver.

View raw message