openoffice-dev mailing list archives

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

Am 14.03.12 17:09, schrieb Kay Schenk:
> On Wed, Mar 14, 2012 at 1:15 AM, Oliver-Rainer Wittmann<
>>  wrote:
>> Hi,
>> 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.
>> [1]**ProductUpdateService/check.**Update<>
>> [2]****
>> Notification_Protocol<>
>> Best regards, Oliver.
> Oliver--Thanks.
> I too am continuing my investigation, though, since I am NOT a C++ coder,
> well...not so simple.

I have already started to document my findings at [2].
I will continue tomorrow morning (German time).
For short: I think I have found everything which is needed to bring a 
"update service" back. We should discuss when I have provided all my 

Best regards (and stay tuned),

View raw message