On Aug 14, 2012, at 12:09 PM, Oliver-Rainer Wittmann wrote:

> Hi,
> 
> Am 14.08.2012 um 20:52 schrieb Dave Fisher <[email protected]>:
> 
>> 
>> On Aug 14, 2012, at 11:43 AM, Rob Weir wrote:
>> 
>>> On Tue, Aug 14, 2012 at 2:24 PM, Dave Fisher <[email protected]> wrote:
>>>> 
>>>> On Aug 5, 2012, at 11:13 AM, Andrea Pescetti wrote:
>>>> 
>>>>> On 03/08/2012 Rob Weir wrote:
>>>>>> On Fri, Aug 3, 2012 at 6:13 AM, Oliver-Rainer Wittmann
>>>>>> wrote:
>>>>>>> I am planning to give a talk on ApacheCon EU about
>>>>>>> the update function in AOO and the Update Service. In this talk I will 
>>>>>>> give
>>>>>>> a deep insight in its purpose and functionality which should be enough 
>>>>>>> input
>>>>>>> for a corresponding volunteer to create a "real" web service for our 
>>>>>>> Update
>>>>>>> Service. ...
>>>>>> The question is:  how dynamic does it need to be?  It is not like the
>>>>>> upgrade options change minute by minute.  These change slowly, at the
>>>>>> pace of our release cycle, so every few months.
>>>>> 
>>>>> Yes, and traffic is a key factor here. With potentially hundreds of 
>>>>> millions of clients hitting the servers, the biggest problem is not 
>>>>> re-implementing the update service as a web service, but serving it 
>>>>> efficiently. And indeed I agree that staticizing the results somehow 
>>>>> would be good to do, since we have a relatively low number of possible 
>>>>> answers with respect to the number of requests.
>>>> 
>>>> Oliver requested removal of update32 from DNS on INFRA-5112 and now Infra 
>>>> is requesting PPMC agreement.
>>>> 
>>>> Is now a time to discuss cleaning up all of the staroffice urls here:
>>>> 
>>>> update.services               CNAME     sd-web4.staroffice.de.
>>>> update23.services             CNAME     sd-web2.staroffice.de.
>>>> update24.services             CNAME     sd-web2.staroffice.de.
>>>> update30.services             CNAME     sd-web2.staroffice.de.
>>>> update31.services             CNAME     sd-web2.staroffice.de.
>>>> update32.services             CNAME     www.openoffice.org.
>>>> update33.services             CNAME     sd-web2.staroffice.de.
>>>> update34.services             CNAME     www.openoffice.org.
>>>> update35.services             CNAME     www.openoffice.org.
>>>> update36.services             CNAME     www.openoffice.org.
>>>> update38.services             CNAME     www.openoffice.org.
>>>> 
>>>> update32 is the proposed change in the JIRA issue.
>>>> 
>>>> update33 is the added removal.
>>>> 
>>>> What about update, update23, update24, update30, update31?
>>>> 
>>>> Should we do anything now as well?
>>>> 
>>> 
>>> I suppose returning errors from *.openoffice.org is no worse than
>>> returning errors from *.staroffice.de.  And if we do that we can
>>> handle these URL's more gracefully in the future if we want to.
>> 
>> It might be nicer to return a 404 rather than timing out on a non-responsive 
>> ip address.
>> 
>> Oliver or Kay will need to confirm what will happen.
> 
> I would like to see a 404 for all currently unused updateX*.services URLs.
> The former OOo versions which would get in contact with these URLs should 
> handle such replies.

The following are current in ooo-site/trunk/content/projects/.

update:
ProductUpdateService    aoo341

update30:
ProductUpdateService

update34:
ProductUpdateService

update35:
ProductUpdateService

update36:
ProductUpdateService

update38:
ProductUpdateService

(1) Are update/ProductUpdateSerice and update30/ProductUpdateService ready?

(2) Currently all 404s on openoffice.org go here:

   ErrorDocument 404 /docs/custom_404.html

Is that acceptable? Or must we use a real 404 response?

Regards,
Dave

> 
> Best regards, Oliver.
> 
> 

Reply via email to