incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kay Schenk <>
Subject Re: update service [was: Re: Apache OpenOffice Extensions Website restored at SourceForge]
Date Wed, 14 Mar 2012 16:09:33 GMT
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.


I too am continuing my investigation, though, since I am NOT a C++ coder,
well...not so simple.


"Follow your bliss."
         -- attributed to Joseph Campbell

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message