incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver-Rainer Wittmann <>
Subject update service [was: Re: Apache OpenOffice Extensions Website restored at SourceForge]
Date Wed, 14 Mar 2012 08:15:13 GMT

On 13.03.2012 17:53, Kay Schenk wrote:
> On Tue, Mar 13, 2012 at 5:54 AM, Roberto Galoppini<>wrote:
> [snipping a lot ...]
>> We have already investigated how it works, and we do actually serve
>> updates requests answering that there are no updates. This is just as
>> it was configured before.
>> Any information about how the update protocol works would be helpful
>> for the future, though.
>> Roberto
> OK, I have an odd question. Is this the same "update protocol" that is used
> to update the actual base package -- i.e. OOo -- the same "update"
> capability that is currently missing from, say, the existing Linux 32-bit
> build?
> Roberto-- where can we get more info on what is actually being "served" in
> response to update request? That is, the URL for it.
> *IF* the same "update protocol" is used for everything, base package and
> extensions, here is what I (we) know. Apparently, there was some
> proprietary tool in place from what I gather in which entries were
> (manually?) entered for "products". That tool created atom feeds at a
> specified URL which the "products/extensions" would then reference for
> updates.
> In building, both Regina and Ariel were able to successfully test an
> "update" by creating an atom feed with a single entry for their respective
> platforms (windows, linux-64 with debian packaging), and I think actually
> perform the update.
> There is information on the "format" of the feed on the wiki:
> but NOTHING about how the feed gets constructed.
> I have been wanting to experiment with adding more than one entry to the
> existing sample feed I ported  (usign Ariel's test) to:
> If someone knows enough to add more "entries" to this feed complying to
> "atom" rules, that would be great. I don't know anything about how
> "matches" occur in this context.

I am testing the function Menu Help - Check for Updates... regarding, if it is 
working after we had back an HTTP/WebDAV client library.
It mainly works using [1]. But, I have recognized that the HTTP header fields 
specified at [2] are not transfered - mea culpa.
--> I will submit a corresponding issue for which I will request the release 
blocker flag.

It looks like that the former update service used the values of the HTTP header 
fields "User-Agent" and "Accept-Language" in order to provide a proper reply.
I think "User-Agent" was used to determine, if for the requested installed 
version an update exists or not. "Accept-Language" seems to be used provide a 
corresponding localized reply.
These are only guesses. Feel free to correct or even support me.

After fixing the above mentioned issue I will try to analyse the code processing 
the response in order to continue Regina's and Ariel's work here.
I expect that it results in proper information which enabled us to provide a 
'static' reply which will signal to all OOo 3.3 versions that AOO 3.4 is available.


Best regards, Oliver.

View raw message