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: Info about the update protocol
Date Thu, 29 Mar 2012 17:15:42 GMT
On Thu, Mar 29, 2012 at 2:23 AM, Oliver-Rainer Wittmann <
orwittmann@googlemail.com> wrote:

> Hi Joe,
>
>
> On 29.03.2012 03:31, Joe Schaefer wrote:
>
>> Look I'm pretty serious about the situation as
>> it stands.  If someone can just give me a little
>> pointer to where the update client is implemented
>> in the svn tree that would be great.
>>
>
> You will find the main stuff in /main/extensions/source/**update/check.
> In updateprotokoll.cxx you will find function <checkForUpdates(..)>.
> Please have also a look at [1], esp. [2].
>
> Our UCB (Universal Content Broker) is used to get the update information
> (an response in XML format) via the URL which is given in the <version.ini>
> resp. <versionrc> file. The URL is found at item <UpdateURL> in this file.
>
> I have have checked what kind of HTTP requests are triggered by our "Check
> for Updates" function. It is a GET request. It should be a single one.
>

a ha! So...maybe the business we saw on Tuesday was from an older
implementation  that used "POST" instead of "GET". I was going to spend
some time today looking into this Oliver. So --THANK YOU!

OK, next question... do you or anyone else happen to have a mapping between
update host names and versions to which they apply?

We redirected "update.services.openoffice.org" which MAY be the URL for
older clients that used "POST" instead of "GET". I don't know version of
OOo this would have been configured for.

Should we assume that all the update3x.service.openoffice.org

apply to OpenOffice.org 3.x clients which are probably implementing the
corrected protocol -- GET vs POST?

I'm happy we're making progress on this!

ps. I also found update23.services.openoffice.org and
update24.openoffice.org as valid DNS entries which we definitely NOT
re-rotue probably due to the same issues.


As I only looked at the current code this might not be the same for former
> OpenOffice.org instances.
>
> [1] http://wiki.services.**openoffice.org/wiki/Update_**
> Notification_Protocol<http://wiki.services.openoffice.org/wiki/Update_Notification_Protocol>
> [2] http://wiki.services.**openoffice.org/wiki/Update_**
> Notification_Protocol#A_**glance_on_the_code_for_the_**
> Apache_OpenOffice_3.4_release<http://wiki.services.openoffice.org/wiki/Update_Notification_Protocol#A_glance_on_the_code_for_the_Apache_OpenOffice_3.4_release>
>
> If you need further information etc., do not hesitate to ask - I will give
> my best to support you.
>
>
> Best regards, Oliver.
>
>
>
>> There is work to do here to integrate the update
>> service into Apache's mirror infrastructure, and
>> the division of labor between what the project can
>> do and what infra needs to do isn't clear at all
>> right now.  It'd sure be nice to have a solution
>> implemented prior to AOO 3.4's release, which I'm
>> trying to accommodate but my time is limited.
>>
>>
>>
>>
>>  ______________________________**__
>>> From: Joe Schaefer<joe_schaefer@yahoo.**com <joe_schaefer@yahoo.com>>
>>> To: "ooo-dev@incubator.apache.org"**<ooo-dev@incubator.apache.org>
>>> Sent: Wednesday, March 28, 2012 10:33 AM
>>> Subject: Info about the update protocol
>>>
>>>
>>> Looking at the most recent experiment with
>>> updates.services.apache.org does not inspire
>>> my confidence that this service was well-thought-out
>>> because it shouldn't be possible for j random user
>>> to configure it to poll continuously for updates.
>>> I can only hope that future variants of the service
>>> were better designed from a network utility standpoint.
>>>
>>>
>>> In any case is there any reason to suspect that throwing
>>> this traffic at a protocol-compliant script will be able to
>>> tell clients to back off?  Where is the update protocol
>>> documented in case infra needs to write a more scalable
>>> implementation of it as an Apache C module?  Any tips,
>>> especially a willingness by volunteers to resolve outstanding
>>> scaling issues, will be appreciated by both infra and your
>>> users of the service.
>>>
>>>
>>> TIA
>>>
>>>
>>>
>>>
>>>
>>>
>>>


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

"Women and cats will do as they please,
 and men and dogs should relax and get used to the idea."
                                                                    --
Robert Heinlein

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