You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Oliver-Rainer Wittmann <or...@googlemail.com> on 2012/05/15 14:11:20 UTC
[UPDATE SERVICE] proposal for a AOO 3.4 update service
Hi,
From my point of view it would make sense to reactivate a simple update service
for AOO 3.4.
The update URL for AOO 3.4 is:
http://update38.services.openoffice.org/ProductUpdateService/check.Update (plus
a query part ?pkgfmt=<pkgformat> for non-Windows platforms)
As this URL resolves to nothing, the user currently gets the following response
from the update functionality in AOO 3.4:
Status: Checking for an update failed.
Description: General Internet error has occurred.
I propose provide the following XML document when a HTTP GET request to the
above given URL is made:
<?xml version="1.0" encoding="UTF-8"?>
<inst:description xmlns:inst="http://installation.openoffice.org/description">
</inst:description>
Kay already made such an XML document available at:
http://www.openoffice.org/ProductUpdateService/check.Update
This response would allow the update functionality in AOO 3.4 to return to the
user that the version is up to date.
Thus, to reactivate an working update service for AOO 3.4 a redirection is needed.
Can somebody make this happen?
I have to admit that do not have the knowledge to do it on my own.
Best regards, Oliver.
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal for a AOO 3.4 update
service
Posted by Shane Curcuru <as...@shanecurcuru.org>.
AOO340m1(Build:9590) - Rev. 1327774
Microsoft Windows [Version 6.1.7601]
Which is Win7 SP1
- Shane
On 2012-05-21 10:43 AM, Oliver-Rainer Wittmann wrote:
> Hi
>
> On 21.05.2012 16:35, Shane Curcuru wrote:
>> "OpenOffice.org 3.4 is up to date." Yay! Fast work indeed #asfinfra folk!
>>
>> Although we should update the product name there for the next build, eh?
>>
>
> Thanks for the test.
>
> Yes, infrastructure is very kind.
>
> One little question: On which operating system do you have your AOO 3.4
> instance running.
>
> Yes, I have already seen the "old" strings.
>
>
> Best regards, Oliver.
>
>
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal for a AOO 3.4 update
service
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi
On 21.05.2012 16:35, Shane Curcuru wrote:
> "OpenOffice.org 3.4 is up to date." Yay! Fast work indeed #asfinfra folk!
>
> Although we should update the product name there for the next build, eh?
>
Thanks for the test.
Yes, infrastructure is very kind.
One little question: On which operating system do you have your AOO 3.4 instance
running.
Yes, I have already seen the "old" strings.
Best regards, Oliver.
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal for a AOO 3.4 update
service
Posted by Shane Curcuru <as...@shanecurcuru.org>.
"OpenOffice.org 3.4 is up to date." Yay! Fast work indeed #asfinfra folk!
Although we should update the product name there for the next build, eh?
- Shane
On 2012-05-21 10:30 AM, Oliver-Rainer Wittmann wrote:
> Hi,
>
> On 21.05.2012 15:29, Oliver-Rainer Wittmann wrote:
>> Hi,
>>
>> On 21.05.2012 13:55, Oliver-Rainer Wittmann wrote:
>>> Hi,
>>>
>>> On 15.05.2012 20:45, Oliver-Rainer Wittmann wrote:
>>>> Hi,
>>>>
>>>> Am 15.05.12 16:11, schrieb Rob Weir:
>>>>> On Tue, May 15, 2012 at 8:11 AM, Oliver-Rainer Wittmann
>>>>> <or...@googlemail.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> From my point of view it would make sense to reactivate a simple
>>>>>> update
>>>>>> service for AOO 3.4.
>>>>>>
>>>>>> The update URL for AOO 3.4 is:
>>>>>> http://update38.services.openoffice.org/ProductUpdateService/check.Update
>>>>>>
>>>>>> (plus a query part ?pkgfmt=<pkgformat> for non-Windows platforms)
>>>>>>
>>>>>> As this URL resolves to nothing, the user currently gets the
>>>>>> following
>>>>>> response from the update functionality in AOO 3.4:
>>>>>> Status: Checking for an update failed.
>>>>>> Description: General Internet error has occurred.
>>>>>>
>>>>>> I propose provide the following XML document when a HTTP GET
>>>>>> request to the
>>>>>> above given URL is made:
>>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>>> <inst:description
>>>>>> xmlns:inst="http://installation.openoffice.org/description">
>>>>>> </inst:description>
>>>>>>
>>>>>> Kay already made such an XML document available at:
>>>>>> http://www.openoffice.org/ProductUpdateService/check.Update
>>>>>>
>>>>>> This response would allow the update functionality in AOO 3.4 to
>>>>>> return to
>>>>>> the user that the version is up to date.
>>>>>>
>>>>>> Thus, to reactivate an working update service for AOO 3.4 a
>>>>>> redirection is
>>>>>> needed.
>>>>>>
>>>>>
>>>>> Are proposing that we just have a static XML file and redirect the
>>>>> requests so it loads that static file?
>>>>>
>>>>
>>>> Yes, as a short-term and fast solution.
>>>>
>>>>> I can see that as being a useful short-term solution. But soon we'll
>>>>> need some more complicated logic, right? For example, when we enable
>>>>> the 3.3. update check, we'll need to know that updates are available
>>>>> for some languages, but not others. Can we do that all with
>>>>> redirection to static files? Or do we need server-based logic, i.e.,
>>>>> a cgi script?
>>>>>
>>>>
>>>> Static files would be possible, because each version has its own
>>>> update service
>>>> URL, but it would be not the best solution for the long-term.
>>>> Thus, some server-based logic would make sense.
>>>>
>>>>> If we're going to need a cgi script in the end, I wonder if it makes
>>>>> sense to start with one now? We could have a simply script that today
>>>>> just always points to the "no update available" XML for AOO 3.4. But
>>>>> then we make it more complicated as we go.
>>>>>
>>>>
>>>> I am currently in preparation of a proposal for an update service
>>>> for OOo 3.3
>>>> installations. Here, I can/will demonstrate how a server-based logic
>>>> would look
>>>> like.
>>>>
>>>>>> Can somebody make this happen?
>>>>>> I have to admit that do not have the knowledge to do it on my own.
>>>>>>
>>>>>
>>>>> If we just redirect to a static file, I think you can just enter a
>>>>> JIRA request for Infra. If we go with a cgi script then we need
>>>>> someone to develop that script first.
>>>>>
>>>>
>>>> If nobody objects, I would go for this short-term and static
>>>> approach and would
>>>> ask via JIRA request for Infra, if the redirect to the already
>>>> existing static
>>>> file can be established.
>>>>
>>>
>>> Ok, let us drive this issue a little bit more.
>>>
>>> For the static and short-term update service for AOO 3.4 I will do
>>> the following:
>>> - Creation of HTTP resource [1] provided the above given simple XML
>>> document
>>
>> Done.
>>
>>> - Asking ASF Infrastructure via corresponding JIRA issue to redirect
>>> HTTP GET
>>> requests for URL [2] (Update URL of AOO 3.4) to URL [2]
>>
>> Done - https://issues.apache.org/jira/browse/INFRA-4830
>>
>
> The infrastructure team was reacting very fast.
> The redirect is established.
>
> Thus, please check in your AOO 3.4 installation, if the update
> functionality returns that your installation is up to date.
>
> Thanks in advance, Oliver
>
>>>
>>> [1]
>>> http://www.openoffice.org/projects/update38/ProductUpdateService/check.Update
>>>
>>> [2]
>>> http://update38.services.openoffice.org/ProductUpdateService/check.Update
>>>
>>>
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal for a AOO 3.4 update
service
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 22.05.2012 10:28, Andrea Pescetti wrote:
> Oliver-Rainer Wittmann wrote:
>> Thus, you got an error in the AOO 3.4 update functionality, because you
>> have an own redirect from openoffice.org to another host. Right?
>> Does the update functionality works, if you do not have your own redirect?
>> I am asking in order to be sure that I got the right message.
>
> It worked correctly. I had setup that redirect on my machine just to moderate
> lists on the legacy infrastructure after the DNS change (Oracle to Apache) had
> been completed; it is now useless of course. When I removed my redirect,
> everything worked as expected and I received a message saying that no updates
> were available.
>
Thanks for the feedback.
Thus, I think there is no need to follow-up this the infrastructure team.
Best regards, Oliver.
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal for a AOO 3.4 update service
Posted by Paulo de Souza Lima <pa...@varekai.org>.
2012/5/22 Paulo de Souza Lima <pa...@varekai.org>
>
>
> 2012/5/22 Oliver-Rainer Wittmann <or...@googlemail.com>
>
>> Hi,
>>
>> On 22.05.2012 10:35, Rory O'Farrell wrote:
>>
>>> On Tue, 22 May 2012 10:28:15 +0200 Andrea Pescetti<pe...@apache.org>
>>>
>>> wrote:
>>>
>>> Oliver-Rainer Wittmann wrote:
>>>>
>>>>> Thus, you got an error in the AOO 3.4 update functionality, because you
>>>>> have an own redirect from openoffice.org to another host. Right? Does
>>>>> the
>>>>> update functionality works, if you do not have your own redirect? I am
>>>>> asking in order to be sure that I got the right message.
>>>>>
>>>>
>>>> It worked correctly. I had setup that redirect on my machine just to
>>>> moderate lists on the legacy infrastructure after the DNS change
>>>> (Oracle to
>>>> Apache) had been completed; it is now useless of course. When I removed
>>>> my
>>>> redirect, everything worked as expected and I received a message saying
>>>> that no updates were available.
>>>>
>>>>
>>> Worked very nicely for me using AOO 3.4. Will try later with an OOo 3.3
>>> machine when it is awake. Congratulations!
>>>
>>>
>> Thanks for the test.
>>
>> The update service for installed OOo 3.3 instance has not be established,
>> yet.
>>
>> Best regards, Oliver.
>>
>
> Hi. I tried here in my office, through an authenticated proxy. It works,
> but it asks for the proxy user and password many times, even if I check the
> "Enable password" option.
>
> Cheers.
>
> --
> Paulo de Souza Lima
> http://almalivre.wordpress.com
> Curitiba - PR
> Linux User #432358
> Ubuntu User #28729
>
>
>
Sorry. The option is actually "Remember password".
--
Paulo de Souza Lima
http://almalivre.wordpress.com
Curitiba - PR
Linux User #432358
Ubuntu User #28729
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal for a AOO 3.4 update service
Posted by Paulo de Souza Lima <pa...@varekai.org>.
2012/5/22 Juergen Schmidt <jo...@googlemail.com>
> Am Dienstag, 22. Mai 2012 um 15:53 schrieb Paulo de Souza Lima:
> > 2012/5/22 Oliver-Rainer Wittmann <or...@googlemail.com>
> >
> > > Hi,
> > >
> > >
> > > On 22.05.2012 14:56, Oliver-Rainer Wittmann wrote:
> > >
> > > > On 22.05.2012 14:47, Paulo de Souza Lima wrote:
> > > >
> > > > > 2012/5/22 Oliver-Rainer Wittmann<orwittmann@**googlemail.com<
> orwittmann@googlemail.com>
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > Oliver-Rainer Wittmann wrote:
> > > > > > >
> > > > > > > >
> > > > > > > > Thus, you got an error in the AOO 3.4 update functionality,
> because
> > > > > > > > > you
> > > > > > > > > have an own redirect from openoffice.org to another host.
> Right?
> > > > > > > > > Does
> > > > > > > > > the
> > > > > > > > > update functionality works, if you do not have your own
> redirect? I
> > > > > > > > > am
> > > > > > > > > asking in order to be sure that I got the right message.
> > > > > > > > >
> > > > > > > >
> > > > > > > > It worked correctly. I had setup that redirect on my machine
> just to
> > > > > > > > moderate lists on the legacy infrastructure after the DNS
> change
> > > > > > > > (Oracle
> > > > > > > > to
> > > > > > > > Apache) had been completed; it is now useless of course.
> When I
> > > > > > > > removed
> > > > > > > > my
> > > > > > > > redirect, everything worked as expected and I received a
> message
> > > > > > > > saying
> > > > > > > > that no updates were available.
> > > > > > > >
> > > > > > > >
> > > > > > > > Worked very nicely for me using AOO 3.4. Will try later with
> an OOo
> > > > > > > 3.3
> > > > > > > machine when it is awake. Congratulations!
> > > > > > >
> > > > > > >
> > > > > > > Thanks for the test.
> > > > > >
> > > > > > The update service for installed OOo 3.3 instance has not be
> > > > > > established,
> > > > > > yet.
> > > > > >
> > > > > > Best regards, Oliver.
> > > > > Hi. I tried here in my office, through an authenticated proxy. It
> works,
> > > > > but it asks for the proxy user and password many times, even if I
> check
> > > > > the
> > > > > "Enable password" option.
> > > > >
> > > >
> > > > Hm..
> > > > As far as I know only one HTTP GET request is performed internally
> by AOO
> > > > 3.4.
> > > > May be due to the redirects more requests are made - I'll have to
> check
> > > > it.
> > > >
> > >
> > >
> > > I have checked it.
> > > Due to the redirect three HTTP GET request are performed.
> > > The first goes to http://update38.services.**openoffice.org/**
> > > ProductUpdateService/check.**Update<
> http://update38.services.openoffice.org/ProductUpdateService/check.Update
> >,
> > > the second to http://openoffice.org/**projects/update38/**
> > > ProductUpdateService/check.**Update<
> http://openoffice.org/projects/update38/ProductUpdateService/check.Update>and
> the final one to
> > > http://www.openoffice.org/**projects/update38/**
> > > ProductUpdateService/check.**Update<
> http://www.openoffice.org/projects/update38/ProductUpdateService/check.Update
> >
> > > The same URLs that Andrea already figured out.
> > >
> > >
> > > I think the "Remember password" option is part of your proxy software.
> > > > Thus, I
> > > > do not think that its functionality is related to AOO 3.4.
> > > >
> > >
> > > May be each HTTP GET request needs to be authenticated in your proxy
> > > software.
> > >
> > > Best regards, Oliver.
> >
> > Suggestion: maybe including fields for proxy user and password in Tools >
> > Option > Internet > Proxy. An option for socks proxy shoud be usefull
> also.
> >
> >
>
> I think it is already possible to configure a proxy. And in case no proxy
> is configured in the office the system proxy is used as far as I know.
> Maybe we have a minor problem here with the new WebDAV/http implementation.
>
> But in general a proxy can be configured.
>
>
Yes, thanks. I've tested using manual proxy options and it worked without
continuous password requests.
> Juergen
>
Regards
> >
> > --
> > Paulo de Souza Lima
> > http://almalivre.wordpress.com
> > Curitiba - PR
> > Linux User #432358
> > Ubuntu User #28729
> >
> >
>
>
>
--
Paulo de Souza Lima
http://almalivre.wordpress.com
Curitiba - PR
Linux User #432358
Ubuntu User #28729
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal for a AOO 3.4
update service
Posted by Juergen Schmidt <jo...@googlemail.com>.
Am Dienstag, 22. Mai 2012 um 15:53 schrieb Paulo de Souza Lima:
> 2012/5/22 Oliver-Rainer Wittmann <or...@googlemail.com>
>
> > Hi,
> >
> >
> > On 22.05.2012 14:56, Oliver-Rainer Wittmann wrote:
> >
> > > On 22.05.2012 14:47, Paulo de Souza Lima wrote:
> > >
> > > > 2012/5/22 Oliver-Rainer Wittmann<or...@googlemail.com>
> > > > >
> > > >
> > > >
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > Oliver-Rainer Wittmann wrote:
> > > > > >
> > > > > > >
> > > > > > > Thus, you got an error in the AOO 3.4 update functionality, because
> > > > > > > > you
> > > > > > > > have an own redirect from openoffice.org to another host. Right?
> > > > > > > > Does
> > > > > > > > the
> > > > > > > > update functionality works, if you do not have your own redirect? I
> > > > > > > > am
> > > > > > > > asking in order to be sure that I got the right message.
> > > > > > > >
> > > > > > >
> > > > > > > It worked correctly. I had setup that redirect on my machine just to
> > > > > > > moderate lists on the legacy infrastructure after the DNS change
> > > > > > > (Oracle
> > > > > > > to
> > > > > > > Apache) had been completed; it is now useless of course. When I
> > > > > > > removed
> > > > > > > my
> > > > > > > redirect, everything worked as expected and I received a message
> > > > > > > saying
> > > > > > > that no updates were available.
> > > > > > >
> > > > > > >
> > > > > > > Worked very nicely for me using AOO 3.4. Will try later with an OOo
> > > > > > 3.3
> > > > > > machine when it is awake. Congratulations!
> > > > > >
> > > > > >
> > > > > > Thanks for the test.
> > > > >
> > > > > The update service for installed OOo 3.3 instance has not be
> > > > > established,
> > > > > yet.
> > > > >
> > > > > Best regards, Oliver.
> > > > Hi. I tried here in my office, through an authenticated proxy. It works,
> > > > but it asks for the proxy user and password many times, even if I check
> > > > the
> > > > "Enable password" option.
> > > >
> > >
> > > Hm..
> > > As far as I know only one HTTP GET request is performed internally by AOO
> > > 3.4.
> > > May be due to the redirects more requests are made - I'll have to check
> > > it.
> > >
> >
> >
> > I have checked it.
> > Due to the redirect three HTTP GET request are performed.
> > The first goes to http://update38.services.**openoffice.org/**
> > ProductUpdateService/check.**Update<http://update38.services.openoffice.org/ProductUpdateService/check.Update>,
> > the second to http://openoffice.org/**projects/update38/**
> > ProductUpdateService/check.**Update<http://openoffice.org/projects/update38/ProductUpdateService/check.Update>and the final one to
> > http://www.openoffice.org/**projects/update38/**
> > ProductUpdateService/check.**Update<http://www.openoffice.org/projects/update38/ProductUpdateService/check.Update>
> > The same URLs that Andrea already figured out.
> >
> >
> > I think the "Remember password" option is part of your proxy software.
> > > Thus, I
> > > do not think that its functionality is related to AOO 3.4.
> > >
> >
> > May be each HTTP GET request needs to be authenticated in your proxy
> > software.
> >
> > Best regards, Oliver.
>
> Suggestion: maybe including fields for proxy user and password in Tools >
> Option > Internet > Proxy. An option for socks proxy shoud be usefull also.
>
>
I think it is already possible to configure a proxy. And in case no proxy is configured in the office the system proxy is used as far as I know. Maybe we have a minor problem here with the new WebDAV/http implementation.
But in general a proxy can be configured.
Juergen
>
> --
> Paulo de Souza Lima
> http://almalivre.wordpress.com
> Curitiba - PR
> Linux User #432358
> Ubuntu User #28729
>
>
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal for a AOO 3.4 update service
Posted by Paulo de Souza Lima <pa...@varekai.org>.
2012/5/22 Oliver-Rainer Wittmann <or...@googlemail.com>
> Hi,
>
>
> On 22.05.2012 14:56, Oliver-Rainer Wittmann wrote:
>
>> On 22.05.2012 14:47, Paulo de Souza Lima wrote:
>>
>>> 2012/5/22 Oliver-Rainer Wittmann<or...@googlemail.com>
>>> >
>>>
>>>
>>>>> wrote:
>>>>>
>>>>> Oliver-Rainer Wittmann wrote:
>>>>>
>>>>>>
>>>>>> Thus, you got an error in the AOO 3.4 update functionality, because
>>>>>>> you
>>>>>>> have an own redirect from openoffice.org to another host. Right?
>>>>>>> Does
>>>>>>> the
>>>>>>> update functionality works, if you do not have your own redirect? I
>>>>>>> am
>>>>>>> asking in order to be sure that I got the right message.
>>>>>>>
>>>>>>>
>>>>>> It worked correctly. I had setup that redirect on my machine just to
>>>>>> moderate lists on the legacy infrastructure after the DNS change
>>>>>> (Oracle
>>>>>> to
>>>>>> Apache) had been completed; it is now useless of course. When I
>>>>>> removed
>>>>>> my
>>>>>> redirect, everything worked as expected and I received a message
>>>>>> saying
>>>>>> that no updates were available.
>>>>>>
>>>>>>
>>>>>> Worked very nicely for me using AOO 3.4. Will try later with an OOo
>>>>> 3.3
>>>>> machine when it is awake. Congratulations!
>>>>>
>>>>>
>>>>> Thanks for the test.
>>>>
>>>> The update service for installed OOo 3.3 instance has not be
>>>> established,
>>>> yet.
>>>>
>>>> Best regards, Oliver.
>>>>
>>>>
>>> Hi. I tried here in my office, through an authenticated proxy. It works,
>>> but it asks for the proxy user and password many times, even if I check
>>> the
>>> "Enable password" option.
>>>
>>>
>> Hm..
>> As far as I know only one HTTP GET request is performed internally by AOO
>> 3.4.
>> May be due to the redirects more requests are made - I'll have to check
>> it.
>>
>
> I have checked it.
> Due to the redirect three HTTP GET request are performed.
> The first goes to http://update38.services.**openoffice.org/**
> ProductUpdateService/check.**Update<http://update38.services.openoffice.org/ProductUpdateService/check.Update>,
> the second to http://openoffice.org/**projects/update38/**
> ProductUpdateService/check.**Update<http://openoffice.org/projects/update38/ProductUpdateService/check.Update>and the final one to
> http://www.openoffice.org/**projects/update38/**
> ProductUpdateService/check.**Update<http://www.openoffice.org/projects/update38/ProductUpdateService/check.Update>
> The same URLs that Andrea already figured out.
>
>
> I think the "Remember password" option is part of your proxy software.
>> Thus, I
>> do not think that its functionality is related to AOO 3.4.
>>
>>
> May be each HTTP GET request needs to be authenticated in your proxy
> software.
>
> Best regards, Oliver.
>
Suggestion: maybe including fields for proxy user and password in Tools >
Option > Internet > Proxy. An option for socks proxy shoud be usefull also.
--
Paulo de Souza Lima
http://almalivre.wordpress.com
Curitiba - PR
Linux User #432358
Ubuntu User #28729
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal for a AOO 3.4 update
service
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 22.05.2012 14:56, Oliver-Rainer Wittmann wrote:
> On 22.05.2012 14:47, Paulo de Souza Lima wrote:
>> 2012/5/22 Oliver-Rainer Wittmann<or...@googlemail.com>
>>
>>>>
>>>> wrote:
>>>>
>>>> Oliver-Rainer Wittmann wrote:
>>>>>
>>>>>> Thus, you got an error in the AOO 3.4 update functionality, because you
>>>>>> have an own redirect from openoffice.org to another host. Right? Does
>>>>>> the
>>>>>> update functionality works, if you do not have your own redirect? I am
>>>>>> asking in order to be sure that I got the right message.
>>>>>>
>>>>>
>>>>> It worked correctly. I had setup that redirect on my machine just to
>>>>> moderate lists on the legacy infrastructure after the DNS change (Oracle
>>>>> to
>>>>> Apache) had been completed; it is now useless of course. When I removed
>>>>> my
>>>>> redirect, everything worked as expected and I received a message saying
>>>>> that no updates were available.
>>>>>
>>>>>
>>>> Worked very nicely for me using AOO 3.4. Will try later with an OOo 3.3
>>>> machine when it is awake. Congratulations!
>>>>
>>>>
>>> Thanks for the test.
>>>
>>> The update service for installed OOo 3.3 instance has not be established,
>>> yet.
>>>
>>> Best regards, Oliver.
>>>
>>
>> Hi. I tried here in my office, through an authenticated proxy. It works,
>> but it asks for the proxy user and password many times, even if I check the
>> "Enable password" option.
>>
>
> Hm..
> As far as I know only one HTTP GET request is performed internally by AOO 3.4.
> May be due to the redirects more requests are made - I'll have to check it.
I have checked it.
Due to the redirect three HTTP GET request are performed.
The first goes to
http://update38.services.openoffice.org/ProductUpdateService/check.Update, the
second to
http://openoffice.org/projects/update38/ProductUpdateService/check.Update and
the final one to
http://www.openoffice.org/projects/update38/ProductUpdateService/check.Update
The same URLs that Andrea already figured out.
> I think the "Remember password" option is part of your proxy software. Thus, I
> do not think that its functionality is related to AOO 3.4.
>
May be each HTTP GET request needs to be authenticated in your proxy software.
Best regards, Oliver.
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal for a AOO 3.4 update
service
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 22.05.2012 14:47, Paulo de Souza Lima wrote:
> 2012/5/22 Oliver-Rainer Wittmann<or...@googlemail.com>
>
>>>
>>> wrote:
>>>
>>> Oliver-Rainer Wittmann wrote:
>>>>
>>>>> Thus, you got an error in the AOO 3.4 update functionality, because you
>>>>> have an own redirect from openoffice.org to another host. Right? Does
>>>>> the
>>>>> update functionality works, if you do not have your own redirect? I am
>>>>> asking in order to be sure that I got the right message.
>>>>>
>>>>
>>>> It worked correctly. I had setup that redirect on my machine just to
>>>> moderate lists on the legacy infrastructure after the DNS change (Oracle
>>>> to
>>>> Apache) had been completed; it is now useless of course. When I removed
>>>> my
>>>> redirect, everything worked as expected and I received a message saying
>>>> that no updates were available.
>>>>
>>>>
>>> Worked very nicely for me using AOO 3.4. Will try later with an OOo 3.3
>>> machine when it is awake. Congratulations!
>>>
>>>
>> Thanks for the test.
>>
>> The update service for installed OOo 3.3 instance has not be established,
>> yet.
>>
>> Best regards, Oliver.
>>
>
> Hi. I tried here in my office, through an authenticated proxy. It works,
> but it asks for the proxy user and password many times, even if I check the
> "Enable password" option.
>
Hm..
As far as I know only one HTTP GET request is performed internally by AOO 3.4.
May be due to the redirects more requests are made - I'll have to check it.
I think the "Remember password" option is part of your proxy software. Thus, I
do not think that its functionality is related to AOO 3.4.
Best regards, Oliver.
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal for a AOO 3.4 update service
Posted by Paulo de Souza Lima <pa...@varekai.org>.
2012/5/22 Oliver-Rainer Wittmann <or...@googlemail.com>
> Hi,
>
> On 22.05.2012 10:35, Rory O'Farrell wrote:
>
>> On Tue, 22 May 2012 10:28:15 +0200 Andrea Pescetti<pe...@apache.org>
>>
>> wrote:
>>
>> Oliver-Rainer Wittmann wrote:
>>>
>>>> Thus, you got an error in the AOO 3.4 update functionality, because you
>>>> have an own redirect from openoffice.org to another host. Right? Does
>>>> the
>>>> update functionality works, if you do not have your own redirect? I am
>>>> asking in order to be sure that I got the right message.
>>>>
>>>
>>> It worked correctly. I had setup that redirect on my machine just to
>>> moderate lists on the legacy infrastructure after the DNS change (Oracle
>>> to
>>> Apache) had been completed; it is now useless of course. When I removed
>>> my
>>> redirect, everything worked as expected and I received a message saying
>>> that no updates were available.
>>>
>>>
>> Worked very nicely for me using AOO 3.4. Will try later with an OOo 3.3
>> machine when it is awake. Congratulations!
>>
>>
> Thanks for the test.
>
> The update service for installed OOo 3.3 instance has not be established,
> yet.
>
> Best regards, Oliver.
>
Hi. I tried here in my office, through an authenticated proxy. It works,
but it asks for the proxy user and password many times, even if I check the
"Enable password" option.
Cheers.
--
Paulo de Souza Lima
http://almalivre.wordpress.com
Curitiba - PR
Linux User #432358
Ubuntu User #28729
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal for a AOO 3.4 update
service
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 22.05.2012 10:35, Rory O'Farrell wrote:
> On Tue, 22 May 2012 10:28:15 +0200 Andrea Pescetti<pe...@apache.org>
> wrote:
>
>> Oliver-Rainer Wittmann wrote:
>>> Thus, you got an error in the AOO 3.4 update functionality, because you
>>> have an own redirect from openoffice.org to another host. Right? Does the
>>> update functionality works, if you do not have your own redirect? I am
>>> asking in order to be sure that I got the right message.
>>
>> It worked correctly. I had setup that redirect on my machine just to
>> moderate lists on the legacy infrastructure after the DNS change (Oracle to
>> Apache) had been completed; it is now useless of course. When I removed my
>> redirect, everything worked as expected and I received a message saying
>> that no updates were available.
>>
>
> Worked very nicely for me using AOO 3.4. Will try later with an OOo 3.3
> machine when it is awake. Congratulations!
>
Thanks for the test.
The update service for installed OOo 3.3 instance has not be established, yet.
Best regards, Oliver.
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal for a AOO 3.4 update
service
Posted by Rory O'Farrell <of...@iol.ie>.
On Tue, 22 May 2012 10:28:15 +0200
Andrea Pescetti <pe...@apache.org> wrote:
> Oliver-Rainer Wittmann wrote:
> > Thus, you got an error in the AOO 3.4 update functionality, because you
> > have an own redirect from openoffice.org to another host. Right?
> > Does the update functionality works, if you do not have your own redirect?
> > I am asking in order to be sure that I got the right message.
>
> It worked correctly. I had setup that redirect on my machine just to
> moderate lists on the legacy infrastructure after the DNS change (Oracle
> to Apache) had been completed; it is now useless of course. When I
> removed my redirect, everything worked as expected and I received a
> message saying that no updates were available.
>
Worked very nicely for me using AOO 3.4. Will try later with an OOo 3.3 machine when it is awake. Congratulations!
--
Rory O'Farrell <of...@iol.ie>
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal for a AOO 3.4 update
service
Posted by Andrea Pescetti <pe...@apache.org>.
Oliver-Rainer Wittmann wrote:
> Thus, you got an error in the AOO 3.4 update functionality, because you
> have an own redirect from openoffice.org to another host. Right?
> Does the update functionality works, if you do not have your own redirect?
> I am asking in order to be sure that I got the right message.
It worked correctly. I had setup that redirect on my machine just to
moderate lists on the legacy infrastructure after the DNS change (Oracle
to Apache) had been completed; it is now useless of course. When I
removed my redirect, everything worked as expected and I received a
message saying that no updates were available.
Regards,
Andrea.
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal for a AOO 3.4 update
service
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 22.05.2012 09:43, Andrea Pescetti wrote:
> On 21/05/2012 Oliver-Rainer Wittmann wrote:
>> The redirect is established.
>> Thus, please check in your AOO 3.4 installation, if the update
>> functionality returns that your installation is up to date.
>>>> [1]
>>>> http://www.openoffice.org/projects/update38/ProductUpdateService/check.Update
>>>> [2]
>>>> http://update38.services.openoffice.org/ProductUpdateService/check.Update
>
> Works for me but the URLs are different. I had redirected openoffice.org
> (notice, no www) to another host and I kept getting an error, so I investigated.
>
> As one can see with wget, the current redirect is
> http://update38.services.openoffice.org/ProductUpdateService/check.Update
> ->
> http://openoffice.org/projects/update38/ProductUpdateService/check.Update
> ->
> http://www.openoffice.org/projects/update38/ProductUpdateService/check.Update
> which works but is probably not the cleanest way. Also, it would likely be the
> first resource we use that depends on http://openoffice.org instead of
> http://www.openoffice.org (in Oracle times, the first one was used for Kenai
> resources, the second one was the website).
>
Thanks for testing.
Thus, you got an error in the AOO 3.4 update functionality, because you have an
own redirect from openoffice.org to another host. Right?
Does the update functionality works, if you do not have your own redirect?
I am asking in order to be sure that I got the right message.
I was not aware of the difference between <www.openoffice.org> and <openoffice.org>.
In the JIRA issue INFRA-4830 I had requested a redirect from [2] to [1].
But I got in direct contact with the infrastructure team on its IRC channel
#asfinfra in order to get guidance. The infrastructure team reacted quite fast -
they immediately established the redirect. I am not sure, if I had requested the
same redirect to openoffice.org/... or to www.openoffice.org/... in the IRC
chat. I will check it this the infrastructure team.
Best regards, Oliver.
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal for a AOO 3.4 update
service
Posted by Andrea Pescetti <pe...@apache.org>.
On 21/05/2012 Oliver-Rainer Wittmann wrote:
> The redirect is established.
> Thus, please check in your AOO 3.4 installation, if the update
> functionality returns that your installation is up to date.
>>> [1]
>>> http://www.openoffice.org/projects/update38/ProductUpdateService/check.Update
>>> [2]
>>> http://update38.services.openoffice.org/ProductUpdateService/check.Update
Works for me but the URLs are different. I had redirected openoffice.org
(notice, no www) to another host and I kept getting an error, so I
investigated.
As one can see with wget, the current redirect is
http://update38.services.openoffice.org/ProductUpdateService/check.Update
->
http://openoffice.org/projects/update38/ProductUpdateService/check.Update
->
http://www.openoffice.org/projects/update38/ProductUpdateService/check.Update
which works but is probably not the cleanest way. Also, it would likely
be the first resource we use that depends on http://openoffice.org
instead of http://www.openoffice.org (in Oracle times, the first one was
used for Kenai resources, the second one was the website).
Regards,
Andrea.
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal for a AOO 3.4 update service
Posted by Kay Schenk <ka...@gmail.com>.
On Mon, May 21, 2012 at 7:30 AM, Oliver-Rainer Wittmann <
orwittmann@googlemail.com> wrote:
> Hi,
>
>
> On 21.05.2012 15:29, Oliver-Rainer Wittmann wrote:
>
>> Hi,
>>
>> On 21.05.2012 13:55, Oliver-Rainer Wittmann wrote:
>>
>>> Hi,
>>>
>>> On 15.05.2012 20:45, Oliver-Rainer Wittmann wrote:
>>>
>>>> Hi,
>>>>
>>>> Am 15.05.12 16:11, schrieb Rob Weir:
>>>>
>>>>> On Tue, May 15, 2012 at 8:11 AM, Oliver-Rainer Wittmann
>>>>> <or...@googlemail.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> From my point of view it would make sense to reactivate a simple
>>>>>> update
>>>>>> service for AOO 3.4.
>>>>>>
>>>>>> The update URL for AOO 3.4 is:
>>>>>> http://update38.services.**openoffice.org/**
>>>>>> ProductUpdateService/check.**Update<http://update38.services.openoffice.org/ProductUpdateService/check.Update>
>>>>>> (plus a query part ?pkgfmt=<pkgformat> for non-Windows platforms)
>>>>>>
>>>>>> As this URL resolves to nothing, the user currently gets the following
>>>>>> response from the update functionality in AOO 3.4:
>>>>>> Status: Checking for an update failed.
>>>>>> Description: General Internet error has occurred.
>>>>>>
>>>>>> I propose provide the following XML document when a HTTP GET request
>>>>>> to the
>>>>>> above given URL is made:
>>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>>> <inst:description
>>>>>> xmlns:inst="http://**installation.openoffice.org/**description<http://installation.openoffice.org/description>
>>>>>> ">
>>>>>> </inst:description>
>>>>>>
>>>>>> Kay already made such an XML document available at:
>>>>>> http://www.openoffice.org/**ProductUpdateService/check.**Update<http://www.openoffice.org/ProductUpdateService/check.Update>
>>>>>>
>>>>>> This response would allow the update functionality in AOO 3.4 to
>>>>>> return to
>>>>>> the user that the version is up to date.
>>>>>>
>>>>>> Thus, to reactivate an working update service for AOO 3.4 a
>>>>>> redirection is
>>>>>> needed.
>>>>>>
>>>>>>
>>>>> Are proposing that we just have a static XML file and redirect the
>>>>> requests so it loads that static file?
>>>>>
>>>>>
>>>> Yes, as a short-term and fast solution.
>>>>
>>>> I can see that as being a useful short-term solution. But soon we'll
>>>>> need some more complicated logic, right? For example, when we enable
>>>>> the 3.3. update check, we'll need to know that updates are available
>>>>> for some languages, but not others. Can we do that all with
>>>>> redirection to static files? Or do we need server-based logic, i.e.,
>>>>> a cgi script?
>>>>>
>>>>>
>>>> Static files would be possible, because each version has its own update
>>>> service
>>>> URL, but it would be not the best solution for the long-term.
>>>> Thus, some server-based logic would make sense.
>>>>
>>>> If we're going to need a cgi script in the end, I wonder if it makes
>>>>> sense to start with one now? We could have a simply script that today
>>>>> just always points to the "no update available" XML for AOO 3.4. But
>>>>> then we make it more complicated as we go.
>>>>>
>>>>>
>>>> I am currently in preparation of a proposal for an update service for
>>>> OOo 3.3
>>>> installations. Here, I can/will demonstrate how a server-based logic
>>>> would look
>>>> like.
>>>>
>>>> Can somebody make this happen?
>>>>>> I have to admit that do not have the knowledge to do it on my own.
>>>>>>
>>>>>>
>>>>> If we just redirect to a static file, I think you can just enter a
>>>>> JIRA request for Infra. If we go with a cgi script then we need
>>>>> someone to develop that script first.
>>>>>
>>>>>
>>>> If nobody objects, I would go for this short-term and static approach
>>>> and would
>>>> ask via JIRA request for Infra, if the redirect to the already existing
>>>> static
>>>> file can be established.
>>>>
>>>>
>>> Ok, let us drive this issue a little bit more.
>>>
>>> For the static and short-term update service for AOO 3.4 I will do the
>>> following:
>>> - Creation of HTTP resource [1] provided the above given simple XML
>>> document
>>>
>>
>> Done.
>>
>> - Asking ASF Infrastructure via corresponding JIRA issue to redirect
>>> HTTP GET
>>> requests for URL [2] (Update URL of AOO 3.4) to URL [2]
>>>
>>
>> Done - https://issues.apache.org/**jira/browse/INFRA-4830<https://issues.apache.org/jira/browse/INFRA-4830>
>>
>>
> The infrastructure team was reacting very fast.
> The redirect is established.
>
> Thus, please check in your AOO 3.4 installation, if the update
> functionality returns that your installation is up to date.
>
Oliver--
Good for me! :)
"Up to date"
Linux 32-bit...
>
> Thanks in advance, Oliver
>
>
>
>>> [1] http://www.openoffice.org/**projects/update38/**
>>> ProductUpdateService/check.**Update<http://www.openoffice.org/projects/update38/ProductUpdateService/check.Update>
>>> [2] http://update38.services.**openoffice.org/**
>>> ProductUpdateService/check.**Update<http://update38.services.openoffice.org/ProductUpdateService/check.Update>
>>>
>>>
--
----------------------------------------------------------------------------------------
MzK
"The reports of my death are greatly exaggerated."
-- Mark Twain
[HEADS UP] Re: [UPDATE SERVICE] proposal for a AOO 3.4 update service
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 21.05.2012 15:29, Oliver-Rainer Wittmann wrote:
> Hi,
>
> On 21.05.2012 13:55, Oliver-Rainer Wittmann wrote:
>> Hi,
>>
>> On 15.05.2012 20:45, Oliver-Rainer Wittmann wrote:
>>> Hi,
>>>
>>> Am 15.05.12 16:11, schrieb Rob Weir:
>>>> On Tue, May 15, 2012 at 8:11 AM, Oliver-Rainer Wittmann
>>>> <or...@googlemail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> From my point of view it would make sense to reactivate a simple update
>>>>> service for AOO 3.4.
>>>>>
>>>>> The update URL for AOO 3.4 is:
>>>>> http://update38.services.openoffice.org/ProductUpdateService/check.Update
>>>>> (plus a query part ?pkgfmt=<pkgformat> for non-Windows platforms)
>>>>>
>>>>> As this URL resolves to nothing, the user currently gets the following
>>>>> response from the update functionality in AOO 3.4:
>>>>> Status: Checking for an update failed.
>>>>> Description: General Internet error has occurred.
>>>>>
>>>>> I propose provide the following XML document when a HTTP GET request to the
>>>>> above given URL is made:
>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>> <inst:description
>>>>> xmlns:inst="http://installation.openoffice.org/description">
>>>>> </inst:description>
>>>>>
>>>>> Kay already made such an XML document available at:
>>>>> http://www.openoffice.org/ProductUpdateService/check.Update
>>>>>
>>>>> This response would allow the update functionality in AOO 3.4 to return to
>>>>> the user that the version is up to date.
>>>>>
>>>>> Thus, to reactivate an working update service for AOO 3.4 a redirection is
>>>>> needed.
>>>>>
>>>>
>>>> Are proposing that we just have a static XML file and redirect the
>>>> requests so it loads that static file?
>>>>
>>>
>>> Yes, as a short-term and fast solution.
>>>
>>>> I can see that as being a useful short-term solution. But soon we'll
>>>> need some more complicated logic, right? For example, when we enable
>>>> the 3.3. update check, we'll need to know that updates are available
>>>> for some languages, but not others. Can we do that all with
>>>> redirection to static files? Or do we need server-based logic, i.e.,
>>>> a cgi script?
>>>>
>>>
>>> Static files would be possible, because each version has its own update service
>>> URL, but it would be not the best solution for the long-term.
>>> Thus, some server-based logic would make sense.
>>>
>>>> If we're going to need a cgi script in the end, I wonder if it makes
>>>> sense to start with one now? We could have a simply script that today
>>>> just always points to the "no update available" XML for AOO 3.4. But
>>>> then we make it more complicated as we go.
>>>>
>>>
>>> I am currently in preparation of a proposal for an update service for OOo 3.3
>>> installations. Here, I can/will demonstrate how a server-based logic would look
>>> like.
>>>
>>>>> Can somebody make this happen?
>>>>> I have to admit that do not have the knowledge to do it on my own.
>>>>>
>>>>
>>>> If we just redirect to a static file, I think you can just enter a
>>>> JIRA request for Infra. If we go with a cgi script then we need
>>>> someone to develop that script first.
>>>>
>>>
>>> If nobody objects, I would go for this short-term and static approach and would
>>> ask via JIRA request for Infra, if the redirect to the already existing static
>>> file can be established.
>>>
>>
>> Ok, let us drive this issue a little bit more.
>>
>> For the static and short-term update service for AOO 3.4 I will do the following:
>> - Creation of HTTP resource [1] provided the above given simple XML document
>
> Done.
>
>> - Asking ASF Infrastructure via corresponding JIRA issue to redirect HTTP GET
>> requests for URL [2] (Update URL of AOO 3.4) to URL [2]
>
> Done - https://issues.apache.org/jira/browse/INFRA-4830
>
The infrastructure team was reacting very fast.
The redirect is established.
Thus, please check in your AOO 3.4 installation, if the update functionality
returns that your installation is up to date.
Thanks in advance, Oliver
>>
>> [1] http://www.openoffice.org/projects/update38/ProductUpdateService/check.Update
>> [2] http://update38.services.openoffice.org/ProductUpdateService/check.Update
>>
Re: [UPDATE SERVICE] proposal for a AOO 3.4 update service
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 21.05.2012 13:55, Oliver-Rainer Wittmann wrote:
> Hi,
>
> On 15.05.2012 20:45, Oliver-Rainer Wittmann wrote:
>> Hi,
>>
>> Am 15.05.12 16:11, schrieb Rob Weir:
>>> On Tue, May 15, 2012 at 8:11 AM, Oliver-Rainer Wittmann
>>> <or...@googlemail.com> wrote:
>>>> Hi,
>>>>
>>>> From my point of view it would make sense to reactivate a simple update
>>>> service for AOO 3.4.
>>>>
>>>> The update URL for AOO 3.4 is:
>>>> http://update38.services.openoffice.org/ProductUpdateService/check.Update
>>>> (plus a query part ?pkgfmt=<pkgformat> for non-Windows platforms)
>>>>
>>>> As this URL resolves to nothing, the user currently gets the following
>>>> response from the update functionality in AOO 3.4:
>>>> Status: Checking for an update failed.
>>>> Description: General Internet error has occurred.
>>>>
>>>> I propose provide the following XML document when a HTTP GET request to the
>>>> above given URL is made:
>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>> <inst:description
>>>> xmlns:inst="http://installation.openoffice.org/description">
>>>> </inst:description>
>>>>
>>>> Kay already made such an XML document available at:
>>>> http://www.openoffice.org/ProductUpdateService/check.Update
>>>>
>>>> This response would allow the update functionality in AOO 3.4 to return to
>>>> the user that the version is up to date.
>>>>
>>>> Thus, to reactivate an working update service for AOO 3.4 a redirection is
>>>> needed.
>>>>
>>>
>>> Are proposing that we just have a static XML file and redirect the
>>> requests so it loads that static file?
>>>
>>
>> Yes, as a short-term and fast solution.
>>
>>> I can see that as being a useful short-term solution. But soon we'll
>>> need some more complicated logic, right? For example, when we enable
>>> the 3.3. update check, we'll need to know that updates are available
>>> for some languages, but not others. Can we do that all with
>>> redirection to static files? Or do we need server-based logic, i.e.,
>>> a cgi script?
>>>
>>
>> Static files would be possible, because each version has its own update service
>> URL, but it would be not the best solution for the long-term.
>> Thus, some server-based logic would make sense.
>>
>>> If we're going to need a cgi script in the end, I wonder if it makes
>>> sense to start with one now? We could have a simply script that today
>>> just always points to the "no update available" XML for AOO 3.4. But
>>> then we make it more complicated as we go.
>>>
>>
>> I am currently in preparation of a proposal for an update service for OOo 3.3
>> installations. Here, I can/will demonstrate how a server-based logic would look
>> like.
>>
>>>> Can somebody make this happen?
>>>> I have to admit that do not have the knowledge to do it on my own.
>>>>
>>>
>>> If we just redirect to a static file, I think you can just enter a
>>> JIRA request for Infra. If we go with a cgi script then we need
>>> someone to develop that script first.
>>>
>>
>> If nobody objects, I would go for this short-term and static approach and would
>> ask via JIRA request for Infra, if the redirect to the already existing static
>> file can be established.
>>
>
> Ok, let us drive this issue a little bit more.
>
> For the static and short-term update service for AOO 3.4 I will do the following:
> - Creation of HTTP resource [1] provided the above given simple XML document
Done.
> - Asking ASF Infrastructure via corresponding JIRA issue to redirect HTTP GET
> requests for URL [2] (Update URL of AOO 3.4) to URL [2]
Done - https://issues.apache.org/jira/browse/INFRA-4830
Is there anything else which I have to do - especially regarding the needed
redirect?
Best regards, Oliver.
>
> [1] http://www.openoffice.org/projects/update38/ProductUpdateService/check.Update
> [2] http://update38.services.openoffice.org/ProductUpdateService/check.Update
>
>
> Best regards, Oliver.
Re: [UPDATE SERVICE] proposal for a AOO 3.4 update service
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 15.05.2012 20:45, Oliver-Rainer Wittmann wrote:
> Hi,
>
> Am 15.05.12 16:11, schrieb Rob Weir:
>> On Tue, May 15, 2012 at 8:11 AM, Oliver-Rainer Wittmann
>> <or...@googlemail.com> wrote:
>>> Hi,
>>>
>>> From my point of view it would make sense to reactivate a simple update
>>> service for AOO 3.4.
>>>
>>> The update URL for AOO 3.4 is:
>>> http://update38.services.openoffice.org/ProductUpdateService/check.Update
>>> (plus a query part ?pkgfmt=<pkgformat> for non-Windows platforms)
>>>
>>> As this URL resolves to nothing, the user currently gets the following
>>> response from the update functionality in AOO 3.4:
>>> Status: Checking for an update failed.
>>> Description: General Internet error has occurred.
>>>
>>> I propose provide the following XML document when a HTTP GET request to the
>>> above given URL is made:
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <inst:description
>>> xmlns:inst="http://installation.openoffice.org/description">
>>> </inst:description>
>>>
>>> Kay already made such an XML document available at:
>>> http://www.openoffice.org/ProductUpdateService/check.Update
>>>
>>> This response would allow the update functionality in AOO 3.4 to return to
>>> the user that the version is up to date.
>>>
>>> Thus, to reactivate an working update service for AOO 3.4 a redirection is
>>> needed.
>>>
>>
>> Are proposing that we just have a static XML file and redirect the
>> requests so it loads that static file?
>>
>
> Yes, as a short-term and fast solution.
>
>> I can see that as being a useful short-term solution. But soon we'll
>> need some more complicated logic, right? For example, when we enable
>> the 3.3. update check, we'll need to know that updates are available
>> for some languages, but not others. Can we do that all with
>> redirection to static files? Or do we need server-based logic, i.e.,
>> a cgi script?
>>
>
> Static files would be possible, because each version has its own update service
> URL, but it would be not the best solution for the long-term.
> Thus, some server-based logic would make sense.
>
>> If we're going to need a cgi script in the end, I wonder if it makes
>> sense to start with one now? We could have a simply script that today
>> just always points to the "no update available" XML for AOO 3.4. But
>> then we make it more complicated as we go.
>>
>
> I am currently in preparation of a proposal for an update service for OOo 3.3
> installations. Here, I can/will demonstrate how a server-based logic would look
> like.
>
>>> Can somebody make this happen?
>>> I have to admit that do not have the knowledge to do it on my own.
>>>
>>
>> If we just redirect to a static file, I think you can just enter a
>> JIRA request for Infra. If we go with a cgi script then we need
>> someone to develop that script first.
>>
>
> If nobody objects, I would go for this short-term and static approach and would
> ask via JIRA request for Infra, if the redirect to the already existing static
> file can be established.
>
Ok, let us drive this issue a little bit more.
For the static and short-term update service for AOO 3.4 I will do the following:
- Creation of HTTP resource [1] provided the above given simple XML document
- Asking ASF Infrastructure via corresponding JIRA issue to redirect HTTP GET
requests for URL [2] (Update URL of AOO 3.4) to URL [2]
[1] http://www.openoffice.org/projects/update38/ProductUpdateService/check.Update
[2] http://update38.services.openoffice.org/ProductUpdateService/check.Update
Best regards, Oliver.
Re: [UPDATE SERVICE] proposal for a AOO 3.4 update service
Posted by Kay Schenk <ka...@gmail.com>.
On Wed, May 16, 2012 at 12:26 PM, Rob Weir <ro...@apache.org> wrote:
> On Wed, May 16, 2012 at 3:16 PM, Oliver-Rainer Wittmann
> <or...@googlemail.com> wrote:
> > Hi
> >
> >
> > On 16.05.2012 20:47, Oliver-Rainer Wittmann wrote:
> >>
> >> On 16.05.2012 19:38, Kay Schenk wrote:
> >>>
> >>> On Tue, May 15, 2012 at 11:37 PM, Oliver-Rainer Wittmann<
> >>> orwittmann@googlemail.com> wrote:
> >>>>
> >>>> On 15.05.2012 20:45, Oliver-Rainer Wittmann wrote:
> >>>>>
> >>>>> Am 15.05.12 16:11, schrieb Rob Weir:
> >>>>>
> >>>>>> On Tue, May 15, 2012 at 8:11 AM, Oliver-Rainer Wittmann
> >>>>>> <or...@googlemail.com> wrote:
> >>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> From my point of view it would make sense to reactivate a simple
> >>>>>>> update
> >>>>>>> service for AOO 3.4.
> >>>>>>>
> >>>>>>> The update URL for AOO 3.4 is:
> >>>>>>>
> >>>>>>> http://update38.services.**
> openoffice.org/**ProductUpdateService/check.
> >>>>>>>
> >>>>>>> **Update<
> http://update38.services.openoffice.org/ProductUpdateService/check.Update>
> >>>>>>>
> >>>>>>> (plus a query part ?pkgfmt=<pkgformat> for non-Windows platforms)
> >>>>>>>
> >>>>>>> As this URL resolves to nothing, the user currently gets the
> >>>>>>> following
> >>>>>>> response from the update functionality in AOO 3.4:
> >>>>>>> Status: Checking for an update failed.
> >>>>>>> Description: General Internet error has occurred.
> >>>>>>>
> >>>>>>> I propose provide the following XML document when a HTTP GET
> request
> >>>>>>> to
> >>>>>>> the
> >>>>>>> above given URL is made:
> >>>>>>> <?xml version="1.0" encoding="UTF-8"?>
> >>>>>>> <inst:description
> >>>>>>>
> >>>>>>> xmlns:inst="http://**installation.openoffice.org/**description<
> http://installation.openoffice.org/description>
> >>>>>>>
> >>>>>>> ">
> >>>>>>> </inst:description>
> >>>>>>>
> >>>>>>> Kay already made such an XML document available at:
> >>>>>>>
> >>>>>>> http://www.openoffice.org/**ProductUpdateService/check.**Update<
> http://www.openoffice.org/ProductUpdateService/check.Update>
> >>>>>>>
> >>>>>>>
> >>>>>>> This response would allow the update functionality in AOO 3.4 to
> >>>>>>> return
> >>>>>>> to
> >>>>>>> the user that the version is up to date.
> >>>>>>>
> >>>>>>> Thus, to reactivate an working update service for AOO 3.4 a
> >>>>>>> redirection
> >>>>>>> is
> >>>>>>> needed.
> >>>>>>>
> >>>>>>>
> >>>>>> Are proposing that we just have a static XML file and redirect the
> >>>>>> requests so it loads that static file?
> >>>>>>
> >>>>>>
> >>>>> Yes, as a short-term and fast solution.
> >>>>>
> >>>>> I can see that as being a useful short-term solution. But soon we'll
> >>>>>>
> >>>>>> need some more complicated logic, right? For example, when we enable
> >>>>>> the 3.3. update check, we'll need to know that updates are available
> >>>>>> for some languages, but not others. Can we do that all with
> >>>>>> redirection to static files? Or do we need server-based logic, i.e.,
> >>>>>> a cgi script?
> >>>>>>
> >>>>>>
> >>>>> Static files would be possible, because each version has its own
> update
> >>>>> service
> >>>>> URL, but it would be not the best solution for the long-term.
> >>>>> Thus, some server-based logic would make sense.
> >>>>>
> >>>>> If we're going to need a cgi script in the end, I wonder if it makes
> >>>>>>
> >>>>>> sense to start with one now? We could have a simply script that
> today
> >>>>>> just always points to the "no update available" XML for AOO 3.4. But
> >>>>>> then we make it more complicated as we go.
> >>>>>>
> >>>>>>
> >>>>> I am currently in preparation of a proposal for an update service for
> >>>>> OOo
> >>>>> 3.3
> >>>>> installations. Here, I can/will demonstrate how a server-based logic
> >>>>> would look
> >>>>> like.
> >>>>>
> >>>>> Can somebody make this happen?
> >>>>>>>
> >>>>>>> I have to admit that do not have the knowledge to do it on my own.
> >>>>>>>
> >>>>>>>
> >>>>>> If we just redirect to a static file, I think you can just enter a
> >>>>>> JIRA request for Infra. If we go with a cgi script then we need
> >>>>>> someone to develop that script first.
> >>>>>>
> >>>>>>
> >>>>> If nobody objects, I would go for this short-term and static approach
> >>>>> and
> >>>>> would
> >>>>> ask via JIRA request for Infra, if the redirect to the already
> existing
> >>>>> static
> >>>>> file can be established.
> >>>>>
> >>>>>
> >>>> I will use issue 119361 - https://issues.apache.org/ooo/**
> >>>>
> >>>> show_bug.cgi?id=119361<
> https://issues.apache.org/ooo/show_bug.cgi?id=119361>-
> >>>> to track the progress on this task.
> >>>>
> >>>> Best regards, Oliver.
> >>>>
> >>>
> >>>
> >>> OK, and a very short update on this.
> >>>
> >>> I tried to deal with this and continually ran into issues.
> >>>
> >>> At the simplest, I tired to make up a "generic" update for maybe all
> >>> platforms and languages that would just take them to a page to choose
> an
> >>> update -- basically our download/other.html at this point.
> >>>
> >>
> >> I think here some server-side script is needed.
> >> A complete "generic" solution which provides a "static" XML document is
> to
> >> hard
> >> figure out.
> >>
> >>> However, if you exclude the platform and other particulars in a very
> >>> simple
> >>> XML file, nothing happens -- in other words, the URL is just ignored
> and
> >>> you get a "no updates" message. This is what is in:
> >>> /projects/update36/ProductUpdateService/check.update
> >>> now.
> >>
> >>
> >> That is right.
> >> The update functionality searches in the returned XML for its operating
> >> system
> >> and its architecture and a buildid which is greater than its own. If it
> >> does not
> >> found it, it assumes that no newer version is available.
> >>
> >>>
> >>> Also, life is complicated by appending the "pkgfmt " on update strings
> in
> >>>
> >>> <AOO install directory>/program/versionrc (for linux...name will vary
> >>> depending on OS)
> >>>
> >>
> >> I will do some further checks with the URL query part.
> >>
> >
> > For a "static" solution the URL query part should not be a problem. It
> seems
> > to be completely neglected by the HTTP server.
> > I have currently some static test XML documents on
> > http://people.apache.org/~orw/testupdateservice/
> > The XML documents are included in the HTTP GET response regardless of the
> > URL query part.
> > As I am not an expert of HTTP and HTTP server, please correct me, if I am
> > wrong here.
> >
>
> I'd keep it simple.
>
> Two main tasks:
>
> 1) Identify whether there is an update available for the user's current
> install
>
> 2) Direct the user to that update
>
> I'd keep #2 really really simple. We already know there is an update.
> We already have logic on http://download.openoffice.org for finding
> the correct download. So for #2 just always send the user to
> http://download.openoffice.org.
>
> That approach even does magical things. For example, in the future,
> the user might be running OpenOffice on a 64-bit Windows, but they are
> running 32-bit OO, since that is all that exists. But when we come
> out with a new 64-bit of AOO 3.x, the logic on
> http://download.openoffice.org will automatically suggest it. Ditto
> for better language support. Someone might be running Spanish AOO 3.4
> but then decide to upgrade to Catalan AOO 3.X (assuming it is
> available).
>
> Getting the user to the download site also help us engage them more
> with the ecosystem, whether signing up for announcement list,
> following us on Twitter, showing how they can get involved in the
> project, etc. It is almost always a good idea to send the user to the
> website.
>
> -Rob
>
Hi Rob --
Well as nice as this sounds, we are restrained by the way the update
service is implemented in current code, I believe. I'm fairly certain,
unless someone else can chime in about this, that we're restricted to
returning JUST an XML feed at this point. In future releases, something
else might be proposed.
I think doing much of anything server-side, well unless we could do a
"catch all" generic url (for all platforms and all langugages..) that then
runs a cgi, that DOES something. hmmmm...
I don't know, it could have promise. I wasn't successful in the "do all for
everyone" approach. Maybe there's a trick to specifiying this.
> > Best regards, Oliver.
>
--
----------------------------------------------------------------------------------------
MzK
"The reports of my death are greatly exaggerated."
-- Mark Twain
Re: [UPDATE SERVICE] proposal for a AOO 3.4 update service
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi
On 21.05.2012 18:20, Roberto Galoppini wrote:
>>
>> [snip]
>>
>>>>
>>>> I'd keep it simple.
>>>>
>>>> Two main tasks:
>>>>
>>>> 1) Identify whether there is an update available for the user's current
>>>> install
>>>>
>>>> 2) Direct the user to that update
>>>>
>>>> I'd keep #2 really really simple. We already know there is an update.
>>>> We already have logic on http://download.openoffice.org for finding
>>>> the correct download. So for #2 just always send the user to
>>>> http://download.openoffice.org.
>>>>
>>>> That approach even does magical things. For example, in the future,
>>>> the user might be running OpenOffice on a 64-bit Windows, but they are
>>>> running 32-bit OO, since that is all that exists. But when we come
>>>> out with a new 64-bit of AOO 3.x, the logic on
>>>> http://download.openoffice.org will automatically suggest it. Ditto
>>>> for better language support. Someone might be running Spanish AOO 3.4
>>>> but then decide to upgrade to Catalan AOO 3.X (assuming it is
>>>> available).
>>>>
>>>
>>> Is this what we plan to do for OOo 3.3 users too?
>>>
>>
>> For OOo 3.3 I have made an own proposal - please have a look at thread
>> "[UPDATE SERVICE] proposal a OOo 3.3 update service"
>>
>>
>
> Thanks Olivier,
>
> I'm trying to catch up with that thread too, are you working on
> making it via the AOO download page or direct downloads?
>
Currently, this is open - both is possible.
For Linux installations is would be a little bit complicated, if we decide to go
for a "static" solution.
But more will follow today on the other thread.
Best regards, Oliver.
Re: [UPDATE SERVICE] proposal for a AOO 3.4 update service
Posted by Roberto Galoppini <rg...@geek.net>.
On Mon, May 21, 2012 at 1:43 PM, Oliver-Rainer Wittmann
<or...@googlemail.com> wrote:
> Hi Roberto,
>
>
> On 18.05.2012 19:14, Roberto Galoppini wrote:
>>
>> On Wed, May 16, 2012 at 9:26 PM, Rob Weir<ro...@apache.org> Â wrote:
>>
>>> On Wed, May 16, 2012 at 3:16 PM, Oliver-Rainer Wittmann
>>> <or...@googlemail.com> Â wrote:
>>>>
>>>> Hi
>>>>
>>>>
>>>> On 16.05.2012 20:47, Oliver-Rainer Wittmann wrote:
>>>>>
>>>>>
>>>>> On 16.05.2012 19:38, Kay Schenk wrote:
>>>>>>
>>>>>>
>>>>>> On Tue, May 15, 2012 at 11:37 PM, Oliver-Rainer Wittmann<
>>>>>> orwittmann@googlemail.com> Â wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 15.05.2012 20:45, Oliver-Rainer Wittmann wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Am 15.05.12 16:11, schrieb Rob Weir:
>>>>>>>>
>>>>>>>>> On Tue, May 15, 2012 at 8:11 AM, Oliver-Rainer Wittmann
>>>>>>>>> <or...@googlemail.com> Â wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Â From my point of view it would make sense to reactivate a simple
>>>>>>>>>> update
>>>>>>>>>> service for AOO 3.4.
>>>>>>>>>>
>>>>>>>>>> The update URL for AOO 3.4 is:
>>>>>>>>>>
>>>>>>>>>> http://update38.services.**
>>>
>>> openoffice.org/**ProductUpdateService/check.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> **Update<
>>>
>>>
>>> http://update38.services.openoffice.org/ProductUpdateService/check.Update>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> (plus a query part ?pkgfmt=<pkgformat> Â for non-Windows platforms)
>>>>>>>>>>
>>>>>>>>>> As this URL resolves to nothing, the user currently gets the
>>>>>>>>>> following
>>>>>>>>>> response from the update functionality in AOO 3.4:
>>>>>>>>>> Status: Checking for an update failed.
>>>>>>>>>> Description: General Internet error has occurred.
>>>>>>>>>>
>>>>>>>>>> I propose provide the following XML document when a HTTP GET
>>>
>>> request
>>>>>>>>>>
>>>>>>>>>> to
>>>>>>>>>> the
>>>>>>>>>> above given URL is made:
>>>>>>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>>>>>>> <inst:description
>>>>>>>>>>
>>>>>>>>>> xmlns:inst="http://**installation.openoffice.org/**description<
>>>
>>> http://installation.openoffice.org/description>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ">
>>>>>>>>>> </inst:description>
>>>>>>>>>>
>>>>>>>>>> Kay already made such an XML document available at:
>>>>>>>>>>
>>>>>>>>>> http://www.openoffice.org/**ProductUpdateService/check.**Update<
>>>
>>> http://www.openoffice.org/ProductUpdateService/check.Update>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This response would allow the update functionality in AOO 3.4 to
>>>>>>>>>> return
>>>>>>>>>> to
>>>>>>>>>> the user that the version is up to date.
>>>>>>>>>>
>>>>>>>>>> Thus, to reactivate an working update service for AOO 3.4 a
>>>>>>>>>> redirection
>>>>>>>>>> is
>>>>>>>>>> needed.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> Are proposing that we just have a static XML file and redirect the
>>>>>>>>> requests so it loads that static file?
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Yes, as a short-term and fast solution.
>>>>>>>>
>>>>>>>> I can see that as being a useful short-term solution. But soon we'll
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> need some more complicated logic, right? For example, when we
>>>>>>>>> enable
>>>>>>>>> the 3.3. update check, we'll need to know that updates are
>>>>>>>>> available
>>>>>>>>> for some languages, but not others. Can we do that all with
>>>>>>>>> redirection to static files? Or do we need server-based logic,
>>>>>>>>> i.e.,
>>>>>>>>> a cgi script?
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Static files would be possible, because each version has its own
>>>
>>> update
>>>>>>>>
>>>>>>>> service
>>>>>>>> URL, but it would be not the best solution for the long-term.
>>>>>>>> Thus, some server-based logic would make sense.
>>>>>>>>
>>>>>>>> If we're going to need a cgi script in the end, I wonder if it makes
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> sense to start with one now? We could have a simply script that
>>>
>>> today
>>>>>>>>>
>>>>>>>>> just always points to the "no update available" XML for AOO 3.4.
>>>>>>>>> But
>>>>>>>>> then we make it more complicated as we go.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> I am currently in preparation of a proposal for an update service
>>>>>>>> for
>>>>>>>> OOo
>>>>>>>> 3.3
>>>>>>>> installations. Here, I can/will demonstrate how a server-based logic
>>>>>>>> would look
>>>>>>>> like.
>>>>>>>>
>>>>>>>> Can somebody make this happen?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I have to admit that do not have the knowledge to do it on my own.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> If we just redirect to a static file, I think you can just enter a
>>>>>>>>> JIRA request for Infra. If we go with a cgi script then we need
>>>>>>>>> someone to develop that script first.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> If nobody objects, I would go for this short-term and static
>>>>>>>> approach
>>>>>>>> and
>>>>>>>> would
>>>>>>>> ask via JIRA request for Infra, if the redirect to the already
>>>
>>> existing
>>>>>>>>
>>>>>>>> static
>>>>>>>> file can be established.
>>>>>>>>
>>>>>>>>
>>>>>>> I will use issue 119361 - https://issues.apache.org/ooo/**
>>>>>>>
>>>>>>> show_bug.cgi?id=119361<
>>>
>>> https://issues.apache.org/ooo/show_bug.cgi?id=119361>-
>>>>>>>
>>>>>>> to track the progress on this task.
>>>>>>>
>>>>>>> Best regards, Oliver.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> OK, and a very short update on this.
>>>>>>
>>>>>> I tried to deal with this and continually ran into issues.
>>>>>>
>>>>>> At the simplest, I tired to make up a "generic" update for maybe all
>>>>>> platforms and languages that would just take them to a page to choose
>>>
>>> an
>>>>>>
>>>>>> update -- basically our download/other.html at this point.
>>>>>>
>>>>>
>>>>> I think here some server-side script is needed.
>>>>> A complete "generic" solution which provides a "static" XML document is
>>>
>>> to
>>>>>
>>>>> hard
>>>>> figure out.
>>>>>
>>>>>> However, if you exclude the platform and other particulars in a very
>>>>>> simple
>>>>>> XML file, nothing happens -- in other words, the URL is just ignored
>>>
>>> and
>>>>>>
>>>>>> you get a "no updates" message. This is what is in:
>>>>>> /projects/update36/ProductUpdateService/check.update
>>>>>> now.
>>>>>
>>>>>
>>>>>
>>>>> That is right.
>>>>> The update functionality searches in the returned XML for its operating
>>>>> system
>>>>> and its architecture and a buildid which is greater than its own. If it
>>>>> does not
>>>>> found it, it assumes that no newer version is available.
>>>>>
>>>>>>
>>>>>> Also, life is complicated by appending the "pkgfmt " on update strings
>>>
>>> in
>>>>>>
>>>>>>
>>>>>> <AOO install directory>/program/versionrc (for linux...name will vary
>>>>>> depending on OS)
>>>>>>
>>>>>
>>>>> I will do some further checks with the URL query part.
>>>>>
>>>>
>>>> For a "static" solution the URL query part should not be a problem. It
>>>
>>> seems
>>>>
>>>> to be completely neglected by the HTTP server.
>>>> I have currently some static test XML documents on
>>>> http://people.apache.org/~orw/testupdateservice/
>>>> The XML documents are included in the HTTP GET response regardless of
>>>> the
>>>> URL query part.
>>>> As I am not an expert of HTTP and HTTP server, please correct me, if I
>>>> am
>>>> wrong here.
>>>>
>>>
>>> I'd keep it simple.
>>>
>>> Two main tasks:
>>>
>>> 1) Identify whether there is an update available for the user's current
>>> install
>>>
>>> 2) Direct the user to that update
>>>
>>> I'd keep #2 really really simple. Â We already know there is an update.
>>> Â We already have logic on http://download.openoffice.org for finding
>>> the correct download. Â So for #2 just always send the user to
>>> http://download.openoffice.org.
>>>
>>> That approach even does magical things. Â For example, in the future,
>>> the user might be running OpenOffice on a 64-bit Windows, but they are
>>> running 32-bit OO, since that is all that exists. Â But when we come
>>> out with a new 64-bit of AOO 3.x, the logic on
>>> http://download.openoffice.org will automatically suggest it. Â Ditto
>>> for better language support. Someone might be running Spanish AOO 3.4
>>> but then decide to upgrade to Catalan AOO 3.X (assuming it is
>>> available).
>>>
>>
>> Is this what we plan to do for OOo 3.3 users too?
>>
>
> For OOo 3.3 I have made an own proposal - please have a look at thread
> "[UPDATE SERVICE] proposal a OOo 3.3 update service"
>
>
> Best regards, Oliver.
Thanks Olivier,
I'm trying to catch up with that thread too, are you working on
making it via the AOO download page or direct downloads?
Roberto
>
>
>
>>
>>>
>>> Getting the user to the download site also help us engage them more
>>> with the ecosystem, whether signing up for announcement list,
>>> following us on Twitter, showing how they can get involved in the
>>> project, etc. Â It is almost always a good idea to send the user to the
>>> website.
>>>
>>
>> In this case we might be serving those downloads too. Â Considered the
>> amount of potential users, we'd like to sort out plan as we did for AOO
>> 3.4, so that we can watch traffic and mirror stability.
>>
>>
>
--
====
This e- mail message is intended only for the named recipient(s) above. It
may contain confidential and privileged information. If you are not the
intended recipient you are hereby notified that any dissemination,
distribution or copying of this e-mail and any attachment(s) is strictly
prohibited. If you have received this e-mail in error, please immediately
notify the sender by replying to this e-mail and delete the message and any
attachment(s) from your system. Thank you.
Re: [UPDATE SERVICE] proposal for a AOO 3.4 update service
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi Roberto,
On 18.05.2012 19:14, Roberto Galoppini wrote:
> On Wed, May 16, 2012 at 9:26 PM, Rob Weir<ro...@apache.org> wrote:
>
>> On Wed, May 16, 2012 at 3:16 PM, Oliver-Rainer Wittmann
>> <or...@googlemail.com> wrote:
>>> Hi
>>>
>>>
>>> On 16.05.2012 20:47, Oliver-Rainer Wittmann wrote:
>>>>
>>>> On 16.05.2012 19:38, Kay Schenk wrote:
>>>>>
>>>>> On Tue, May 15, 2012 at 11:37 PM, Oliver-Rainer Wittmann<
>>>>> orwittmann@googlemail.com> wrote:
>>>>>>
>>>>>> On 15.05.2012 20:45, Oliver-Rainer Wittmann wrote:
>>>>>>>
>>>>>>> Am 15.05.12 16:11, schrieb Rob Weir:
>>>>>>>
>>>>>>>> On Tue, May 15, 2012 at 8:11 AM, Oliver-Rainer Wittmann
>>>>>>>> <or...@googlemail.com> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> From my point of view it would make sense to reactivate a simple
>>>>>>>>> update
>>>>>>>>> service for AOO 3.4.
>>>>>>>>>
>>>>>>>>> The update URL for AOO 3.4 is:
>>>>>>>>>
>>>>>>>>> http://update38.services.**
>> openoffice.org/**ProductUpdateService/check.
>>>>>>>>>
>>>>>>>>> **Update<
>> http://update38.services.openoffice.org/ProductUpdateService/check.Update>
>>>>>>>>>
>>>>>>>>> (plus a query part ?pkgfmt=<pkgformat> for non-Windows platforms)
>>>>>>>>>
>>>>>>>>> As this URL resolves to nothing, the user currently gets the
>>>>>>>>> following
>>>>>>>>> response from the update functionality in AOO 3.4:
>>>>>>>>> Status: Checking for an update failed.
>>>>>>>>> Description: General Internet error has occurred.
>>>>>>>>>
>>>>>>>>> I propose provide the following XML document when a HTTP GET
>> request
>>>>>>>>> to
>>>>>>>>> the
>>>>>>>>> above given URL is made:
>>>>>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>>>>>> <inst:description
>>>>>>>>>
>>>>>>>>> xmlns:inst="http://**installation.openoffice.org/**description<
>> http://installation.openoffice.org/description>
>>>>>>>>>
>>>>>>>>> ">
>>>>>>>>> </inst:description>
>>>>>>>>>
>>>>>>>>> Kay already made such an XML document available at:
>>>>>>>>>
>>>>>>>>> http://www.openoffice.org/**ProductUpdateService/check.**Update<
>> http://www.openoffice.org/ProductUpdateService/check.Update>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This response would allow the update functionality in AOO 3.4 to
>>>>>>>>> return
>>>>>>>>> to
>>>>>>>>> the user that the version is up to date.
>>>>>>>>>
>>>>>>>>> Thus, to reactivate an working update service for AOO 3.4 a
>>>>>>>>> redirection
>>>>>>>>> is
>>>>>>>>> needed.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Are proposing that we just have a static XML file and redirect the
>>>>>>>> requests so it loads that static file?
>>>>>>>>
>>>>>>>>
>>>>>>> Yes, as a short-term and fast solution.
>>>>>>>
>>>>>>> I can see that as being a useful short-term solution. But soon we'll
>>>>>>>>
>>>>>>>> need some more complicated logic, right? For example, when we enable
>>>>>>>> the 3.3. update check, we'll need to know that updates are available
>>>>>>>> for some languages, but not others. Can we do that all with
>>>>>>>> redirection to static files? Or do we need server-based logic, i.e.,
>>>>>>>> a cgi script?
>>>>>>>>
>>>>>>>>
>>>>>>> Static files would be possible, because each version has its own
>> update
>>>>>>> service
>>>>>>> URL, but it would be not the best solution for the long-term.
>>>>>>> Thus, some server-based logic would make sense.
>>>>>>>
>>>>>>> If we're going to need a cgi script in the end, I wonder if it makes
>>>>>>>>
>>>>>>>> sense to start with one now? We could have a simply script that
>> today
>>>>>>>> just always points to the "no update available" XML for AOO 3.4. But
>>>>>>>> then we make it more complicated as we go.
>>>>>>>>
>>>>>>>>
>>>>>>> I am currently in preparation of a proposal for an update service for
>>>>>>> OOo
>>>>>>> 3.3
>>>>>>> installations. Here, I can/will demonstrate how a server-based logic
>>>>>>> would look
>>>>>>> like.
>>>>>>>
>>>>>>> Can somebody make this happen?
>>>>>>>>>
>>>>>>>>> I have to admit that do not have the knowledge to do it on my own.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> If we just redirect to a static file, I think you can just enter a
>>>>>>>> JIRA request for Infra. If we go with a cgi script then we need
>>>>>>>> someone to develop that script first.
>>>>>>>>
>>>>>>>>
>>>>>>> If nobody objects, I would go for this short-term and static approach
>>>>>>> and
>>>>>>> would
>>>>>>> ask via JIRA request for Infra, if the redirect to the already
>> existing
>>>>>>> static
>>>>>>> file can be established.
>>>>>>>
>>>>>>>
>>>>>> I will use issue 119361 - https://issues.apache.org/ooo/**
>>>>>>
>>>>>> show_bug.cgi?id=119361<
>> https://issues.apache.org/ooo/show_bug.cgi?id=119361>-
>>>>>> to track the progress on this task.
>>>>>>
>>>>>> Best regards, Oliver.
>>>>>>
>>>>>
>>>>>
>>>>> OK, and a very short update on this.
>>>>>
>>>>> I tried to deal with this and continually ran into issues.
>>>>>
>>>>> At the simplest, I tired to make up a "generic" update for maybe all
>>>>> platforms and languages that would just take them to a page to choose
>> an
>>>>> update -- basically our download/other.html at this point.
>>>>>
>>>>
>>>> I think here some server-side script is needed.
>>>> A complete "generic" solution which provides a "static" XML document is
>> to
>>>> hard
>>>> figure out.
>>>>
>>>>> However, if you exclude the platform and other particulars in a very
>>>>> simple
>>>>> XML file, nothing happens -- in other words, the URL is just ignored
>> and
>>>>> you get a "no updates" message. This is what is in:
>>>>> /projects/update36/ProductUpdateService/check.update
>>>>> now.
>>>>
>>>>
>>>> That is right.
>>>> The update functionality searches in the returned XML for its operating
>>>> system
>>>> and its architecture and a buildid which is greater than its own. If it
>>>> does not
>>>> found it, it assumes that no newer version is available.
>>>>
>>>>>
>>>>> Also, life is complicated by appending the "pkgfmt " on update strings
>> in
>>>>>
>>>>> <AOO install directory>/program/versionrc (for linux...name will vary
>>>>> depending on OS)
>>>>>
>>>>
>>>> I will do some further checks with the URL query part.
>>>>
>>>
>>> For a "static" solution the URL query part should not be a problem. It
>> seems
>>> to be completely neglected by the HTTP server.
>>> I have currently some static test XML documents on
>>> http://people.apache.org/~orw/testupdateservice/
>>> The XML documents are included in the HTTP GET response regardless of the
>>> URL query part.
>>> As I am not an expert of HTTP and HTTP server, please correct me, if I am
>>> wrong here.
>>>
>>
>> I'd keep it simple.
>>
>> Two main tasks:
>>
>> 1) Identify whether there is an update available for the user's current
>> install
>>
>> 2) Direct the user to that update
>>
>> I'd keep #2 really really simple. We already know there is an update.
>> We already have logic on http://download.openoffice.org for finding
>> the correct download. So for #2 just always send the user to
>> http://download.openoffice.org.
>>
>> That approach even does magical things. For example, in the future,
>> the user might be running OpenOffice on a 64-bit Windows, but they are
>> running 32-bit OO, since that is all that exists. But when we come
>> out with a new 64-bit of AOO 3.x, the logic on
>> http://download.openoffice.org will automatically suggest it. Ditto
>> for better language support. Someone might be running Spanish AOO 3.4
>> but then decide to upgrade to Catalan AOO 3.X (assuming it is
>> available).
>>
>
> Is this what we plan to do for OOo 3.3 users too?
>
For OOo 3.3 I have made an own proposal - please have a look at thread "[UPDATE
SERVICE] proposal a OOo 3.3 update service"
Best regards, Oliver.
>
>>
>> Getting the user to the download site also help us engage them more
>> with the ecosystem, whether signing up for announcement list,
>> following us on Twitter, showing how they can get involved in the
>> project, etc. It is almost always a good idea to send the user to the
>> website.
>>
>
> In this case we might be serving those downloads too. Considered the
> amount of potential users, we'd like to sort out plan as we did for AOO
> 3.4, so that we can watch traffic and mirror stability.
>
>
Re: [UPDATE SERVICE] proposal for a AOO 3.4 update service
Posted by Roberto Galoppini <rg...@geek.net>.
On Wed, May 16, 2012 at 9:26 PM, Rob Weir <ro...@apache.org> wrote:
> On Wed, May 16, 2012 at 3:16 PM, Oliver-Rainer Wittmann
> <or...@googlemail.com> wrote:
> > Hi
> >
> >
> > On 16.05.2012 20:47, Oliver-Rainer Wittmann wrote:
> >>
> >> On 16.05.2012 19:38, Kay Schenk wrote:
> >>>
> >>> On Tue, May 15, 2012 at 11:37 PM, Oliver-Rainer Wittmann<
> >>> orwittmann@googlemail.com> wrote:
> >>>>
> >>>> On 15.05.2012 20:45, Oliver-Rainer Wittmann wrote:
> >>>>>
> >>>>> Am 15.05.12 16:11, schrieb Rob Weir:
> >>>>>
> >>>>>> On Tue, May 15, 2012 at 8:11 AM, Oliver-Rainer Wittmann
> >>>>>> <or...@googlemail.com> wrote:
> >>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> From my point of view it would make sense to reactivate a simple
> >>>>>>> update
> >>>>>>> service for AOO 3.4.
> >>>>>>>
> >>>>>>> The update URL for AOO 3.4 is:
> >>>>>>>
> >>>>>>> http://update38.services.**
> openoffice.org/**ProductUpdateService/check.
> >>>>>>>
> >>>>>>> **Update<
> http://update38.services.openoffice.org/ProductUpdateService/check.Update>
> >>>>>>>
> >>>>>>> (plus a query part ?pkgfmt=<pkgformat> for non-Windows platforms)
> >>>>>>>
> >>>>>>> As this URL resolves to nothing, the user currently gets the
> >>>>>>> following
> >>>>>>> response from the update functionality in AOO 3.4:
> >>>>>>> Status: Checking for an update failed.
> >>>>>>> Description: General Internet error has occurred.
> >>>>>>>
> >>>>>>> I propose provide the following XML document when a HTTP GET
> request
> >>>>>>> to
> >>>>>>> the
> >>>>>>> above given URL is made:
> >>>>>>> <?xml version="1.0" encoding="UTF-8"?>
> >>>>>>> <inst:description
> >>>>>>>
> >>>>>>> xmlns:inst="http://**installation.openoffice.org/**description<
> http://installation.openoffice.org/description>
> >>>>>>>
> >>>>>>> ">
> >>>>>>> </inst:description>
> >>>>>>>
> >>>>>>> Kay already made such an XML document available at:
> >>>>>>>
> >>>>>>> http://www.openoffice.org/**ProductUpdateService/check.**Update<
> http://www.openoffice.org/ProductUpdateService/check.Update>
> >>>>>>>
> >>>>>>>
> >>>>>>> This response would allow the update functionality in AOO 3.4 to
> >>>>>>> return
> >>>>>>> to
> >>>>>>> the user that the version is up to date.
> >>>>>>>
> >>>>>>> Thus, to reactivate an working update service for AOO 3.4 a
> >>>>>>> redirection
> >>>>>>> is
> >>>>>>> needed.
> >>>>>>>
> >>>>>>>
> >>>>>> Are proposing that we just have a static XML file and redirect the
> >>>>>> requests so it loads that static file?
> >>>>>>
> >>>>>>
> >>>>> Yes, as a short-term and fast solution.
> >>>>>
> >>>>> I can see that as being a useful short-term solution. But soon we'll
> >>>>>>
> >>>>>> need some more complicated logic, right? For example, when we enable
> >>>>>> the 3.3. update check, we'll need to know that updates are available
> >>>>>> for some languages, but not others. Can we do that all with
> >>>>>> redirection to static files? Or do we need server-based logic, i.e.,
> >>>>>> a cgi script?
> >>>>>>
> >>>>>>
> >>>>> Static files would be possible, because each version has its own
> update
> >>>>> service
> >>>>> URL, but it would be not the best solution for the long-term.
> >>>>> Thus, some server-based logic would make sense.
> >>>>>
> >>>>> If we're going to need a cgi script in the end, I wonder if it makes
> >>>>>>
> >>>>>> sense to start with one now? We could have a simply script that
> today
> >>>>>> just always points to the "no update available" XML for AOO 3.4. But
> >>>>>> then we make it more complicated as we go.
> >>>>>>
> >>>>>>
> >>>>> I am currently in preparation of a proposal for an update service for
> >>>>> OOo
> >>>>> 3.3
> >>>>> installations. Here, I can/will demonstrate how a server-based logic
> >>>>> would look
> >>>>> like.
> >>>>>
> >>>>> Can somebody make this happen?
> >>>>>>>
> >>>>>>> I have to admit that do not have the knowledge to do it on my own.
> >>>>>>>
> >>>>>>>
> >>>>>> If we just redirect to a static file, I think you can just enter a
> >>>>>> JIRA request for Infra. If we go with a cgi script then we need
> >>>>>> someone to develop that script first.
> >>>>>>
> >>>>>>
> >>>>> If nobody objects, I would go for this short-term and static approach
> >>>>> and
> >>>>> would
> >>>>> ask via JIRA request for Infra, if the redirect to the already
> existing
> >>>>> static
> >>>>> file can be established.
> >>>>>
> >>>>>
> >>>> I will use issue 119361 - https://issues.apache.org/ooo/**
> >>>>
> >>>> show_bug.cgi?id=119361<
> https://issues.apache.org/ooo/show_bug.cgi?id=119361>-
> >>>> to track the progress on this task.
> >>>>
> >>>> Best regards, Oliver.
> >>>>
> >>>
> >>>
> >>> OK, and a very short update on this.
> >>>
> >>> I tried to deal with this and continually ran into issues.
> >>>
> >>> At the simplest, I tired to make up a "generic" update for maybe all
> >>> platforms and languages that would just take them to a page to choose
> an
> >>> update -- basically our download/other.html at this point.
> >>>
> >>
> >> I think here some server-side script is needed.
> >> A complete "generic" solution which provides a "static" XML document is
> to
> >> hard
> >> figure out.
> >>
> >>> However, if you exclude the platform and other particulars in a very
> >>> simple
> >>> XML file, nothing happens -- in other words, the URL is just ignored
> and
> >>> you get a "no updates" message. This is what is in:
> >>> /projects/update36/ProductUpdateService/check.update
> >>> now.
> >>
> >>
> >> That is right.
> >> The update functionality searches in the returned XML for its operating
> >> system
> >> and its architecture and a buildid which is greater than its own. If it
> >> does not
> >> found it, it assumes that no newer version is available.
> >>
> >>>
> >>> Also, life is complicated by appending the "pkgfmt " on update strings
> in
> >>>
> >>> <AOO install directory>/program/versionrc (for linux...name will vary
> >>> depending on OS)
> >>>
> >>
> >> I will do some further checks with the URL query part.
> >>
> >
> > For a "static" solution the URL query part should not be a problem. It
> seems
> > to be completely neglected by the HTTP server.
> > I have currently some static test XML documents on
> > http://people.apache.org/~orw/testupdateservice/
> > The XML documents are included in the HTTP GET response regardless of the
> > URL query part.
> > As I am not an expert of HTTP and HTTP server, please correct me, if I am
> > wrong here.
> >
>
> I'd keep it simple.
>
> Two main tasks:
>
> 1) Identify whether there is an update available for the user's current
> install
>
> 2) Direct the user to that update
>
> I'd keep #2 really really simple. We already know there is an update.
> We already have logic on http://download.openoffice.org for finding
> the correct download. So for #2 just always send the user to
> http://download.openoffice.org.
>
> That approach even does magical things. For example, in the future,
> the user might be running OpenOffice on a 64-bit Windows, but they are
> running 32-bit OO, since that is all that exists. But when we come
> out with a new 64-bit of AOO 3.x, the logic on
> http://download.openoffice.org will automatically suggest it. Ditto
> for better language support. Someone might be running Spanish AOO 3.4
> but then decide to upgrade to Catalan AOO 3.X (assuming it is
> available).
>
Is this what we plan to do for OOo 3.3 users too?
>
> Getting the user to the download site also help us engage them more
> with the ecosystem, whether signing up for announcement list,
> following us on Twitter, showing how they can get involved in the
> project, etc. It is almost always a good idea to send the user to the
> website.
>
In this case we might be serving those downloads too. Considered the
amount of potential users, we'd like to sort out plan as we did for AOO
3.4, so that we can watch traffic and mirror stability.
Roberto
>
> -Rob
>
> > Best regards, Oliver.
>
--
====
This e- mail message is intended only for the named recipient(s) above. It
may contain confidential and privileged information. If you are not the
intended recipient you are hereby notified that any dissemination,
distribution or copying of this e-mail and any attachment(s) is strictly
prohibited. If you have received this e-mail in error, please immediately
notify the sender by replying to this e-mail and delete the message and any
attachment(s) from your system. Thank you.
Re: [UPDATE SERVICE] proposal for a AOO 3.4 update service
Posted by Rob Weir <ro...@apache.org>.
On Wed, May 16, 2012 at 3:16 PM, Oliver-Rainer Wittmann
<or...@googlemail.com> wrote:
> Hi
>
>
> On 16.05.2012 20:47, Oliver-Rainer Wittmann wrote:
>>
>> On 16.05.2012 19:38, Kay Schenk wrote:
>>>
>>> On Tue, May 15, 2012 at 11:37 PM, Oliver-Rainer Wittmann<
>>> orwittmann@googlemail.com> wrote:
>>>>
>>>> On 15.05.2012 20:45, Oliver-Rainer Wittmann wrote:
>>>>>
>>>>> Am 15.05.12 16:11, schrieb Rob Weir:
>>>>>
>>>>>> On Tue, May 15, 2012 at 8:11 AM, Oliver-Rainer Wittmann
>>>>>> <or...@googlemail.com> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> From my point of view it would make sense to reactivate a simple
>>>>>>> update
>>>>>>> service for AOO 3.4.
>>>>>>>
>>>>>>> The update URL for AOO 3.4 is:
>>>>>>>
>>>>>>> http://update38.services.**openoffice.org/**ProductUpdateService/check.
>>>>>>>
>>>>>>> **Update<http://update38.services.openoffice.org/ProductUpdateService/check.Update>
>>>>>>>
>>>>>>> (plus a query part ?pkgfmt=<pkgformat> for non-Windows platforms)
>>>>>>>
>>>>>>> As this URL resolves to nothing, the user currently gets the
>>>>>>> following
>>>>>>> response from the update functionality in AOO 3.4:
>>>>>>> Status: Checking for an update failed.
>>>>>>> Description: General Internet error has occurred.
>>>>>>>
>>>>>>> I propose provide the following XML document when a HTTP GET request
>>>>>>> to
>>>>>>> the
>>>>>>> above given URL is made:
>>>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>>>> <inst:description
>>>>>>>
>>>>>>> xmlns:inst="http://**installation.openoffice.org/**description<http://installation.openoffice.org/description>
>>>>>>>
>>>>>>> ">
>>>>>>> </inst:description>
>>>>>>>
>>>>>>> Kay already made such an XML document available at:
>>>>>>>
>>>>>>> http://www.openoffice.org/**ProductUpdateService/check.**Update<http://www.openoffice.org/ProductUpdateService/check.Update>
>>>>>>>
>>>>>>>
>>>>>>> This response would allow the update functionality in AOO 3.4 to
>>>>>>> return
>>>>>>> to
>>>>>>> the user that the version is up to date.
>>>>>>>
>>>>>>> Thus, to reactivate an working update service for AOO 3.4 a
>>>>>>> redirection
>>>>>>> is
>>>>>>> needed.
>>>>>>>
>>>>>>>
>>>>>> Are proposing that we just have a static XML file and redirect the
>>>>>> requests so it loads that static file?
>>>>>>
>>>>>>
>>>>> Yes, as a short-term and fast solution.
>>>>>
>>>>> I can see that as being a useful short-term solution. But soon we'll
>>>>>>
>>>>>> need some more complicated logic, right? For example, when we enable
>>>>>> the 3.3. update check, we'll need to know that updates are available
>>>>>> for some languages, but not others. Can we do that all with
>>>>>> redirection to static files? Or do we need server-based logic, i.e.,
>>>>>> a cgi script?
>>>>>>
>>>>>>
>>>>> Static files would be possible, because each version has its own update
>>>>> service
>>>>> URL, but it would be not the best solution for the long-term.
>>>>> Thus, some server-based logic would make sense.
>>>>>
>>>>> If we're going to need a cgi script in the end, I wonder if it makes
>>>>>>
>>>>>> sense to start with one now? We could have a simply script that today
>>>>>> just always points to the "no update available" XML for AOO 3.4. But
>>>>>> then we make it more complicated as we go.
>>>>>>
>>>>>>
>>>>> I am currently in preparation of a proposal for an update service for
>>>>> OOo
>>>>> 3.3
>>>>> installations. Here, I can/will demonstrate how a server-based logic
>>>>> would look
>>>>> like.
>>>>>
>>>>> Can somebody make this happen?
>>>>>>>
>>>>>>> I have to admit that do not have the knowledge to do it on my own.
>>>>>>>
>>>>>>>
>>>>>> If we just redirect to a static file, I think you can just enter a
>>>>>> JIRA request for Infra. If we go with a cgi script then we need
>>>>>> someone to develop that script first.
>>>>>>
>>>>>>
>>>>> If nobody objects, I would go for this short-term and static approach
>>>>> and
>>>>> would
>>>>> ask via JIRA request for Infra, if the redirect to the already existing
>>>>> static
>>>>> file can be established.
>>>>>
>>>>>
>>>> I will use issue 119361 - https://issues.apache.org/ooo/**
>>>>
>>>> show_bug.cgi?id=119361<https://issues.apache.org/ooo/show_bug.cgi?id=119361>-
>>>> to track the progress on this task.
>>>>
>>>> Best regards, Oliver.
>>>>
>>>
>>>
>>> OK, and a very short update on this.
>>>
>>> I tried to deal with this and continually ran into issues.
>>>
>>> At the simplest, I tired to make up a "generic" update for maybe all
>>> platforms and languages that would just take them to a page to choose an
>>> update -- basically our download/other.html at this point.
>>>
>>
>> I think here some server-side script is needed.
>> A complete "generic" solution which provides a "static" XML document is to
>> hard
>> figure out.
>>
>>> However, if you exclude the platform and other particulars in a very
>>> simple
>>> XML file, nothing happens -- in other words, the URL is just ignored and
>>> you get a "no updates" message. This is what is in:
>>> /projects/update36/ProductUpdateService/check.update
>>> now.
>>
>>
>> That is right.
>> The update functionality searches in the returned XML for its operating
>> system
>> and its architecture and a buildid which is greater than its own. If it
>> does not
>> found it, it assumes that no newer version is available.
>>
>>>
>>> Also, life is complicated by appending the "pkgfmt " on update strings in
>>>
>>> <AOO install directory>/program/versionrc (for linux...name will vary
>>> depending on OS)
>>>
>>
>> I will do some further checks with the URL query part.
>>
>
> For a "static" solution the URL query part should not be a problem. It seems
> to be completely neglected by the HTTP server.
> I have currently some static test XML documents on
> http://people.apache.org/~orw/testupdateservice/
> The XML documents are included in the HTTP GET response regardless of the
> URL query part.
> As I am not an expert of HTTP and HTTP server, please correct me, if I am
> wrong here.
>
I'd keep it simple.
Two main tasks:
1) Identify whether there is an update available for the user's current install
2) Direct the user to that update
I'd keep #2 really really simple. We already know there is an update.
We already have logic on http://download.openoffice.org for finding
the correct download. So for #2 just always send the user to
http://download.openoffice.org.
That approach even does magical things. For example, in the future,
the user might be running OpenOffice on a 64-bit Windows, but they are
running 32-bit OO, since that is all that exists. But when we come
out with a new 64-bit of AOO 3.x, the logic on
http://download.openoffice.org will automatically suggest it. Ditto
for better language support. Someone might be running Spanish AOO 3.4
but then decide to upgrade to Catalan AOO 3.X (assuming it is
available).
Getting the user to the download site also help us engage them more
with the ecosystem, whether signing up for announcement list,
following us on Twitter, showing how they can get involved in the
project, etc. It is almost always a good idea to send the user to the
website.
-Rob
> Best regards, Oliver.
Re: [UPDATE SERVICE] proposal for a AOO 3.4 update service
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi
On 16.05.2012 20:47, Oliver-Rainer Wittmann wrote:
> On 16.05.2012 19:38, Kay Schenk wrote:
>> On Tue, May 15, 2012 at 11:37 PM, Oliver-Rainer Wittmann<
>> orwittmann@googlemail.com> wrote:
>>> On 15.05.2012 20:45, Oliver-Rainer Wittmann wrote:
>>>> Am 15.05.12 16:11, schrieb Rob Weir:
>>>>
>>>>> On Tue, May 15, 2012 at 8:11 AM, Oliver-Rainer Wittmann
>>>>> <or...@googlemail.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> From my point of view it would make sense to reactivate a simple update
>>>>>> service for AOO 3.4.
>>>>>>
>>>>>> The update URL for AOO 3.4 is:
>>>>>> http://update38.services.**openoffice.org/**ProductUpdateService/check.
>>>>>> **Update<http://update38.services.openoffice.org/ProductUpdateService/check.Update>
>>>>>>
>>>>>> (plus a query part ?pkgfmt=<pkgformat> for non-Windows platforms)
>>>>>>
>>>>>> As this URL resolves to nothing, the user currently gets the following
>>>>>> response from the update functionality in AOO 3.4:
>>>>>> Status: Checking for an update failed.
>>>>>> Description: General Internet error has occurred.
>>>>>>
>>>>>> I propose provide the following XML document when a HTTP GET request to
>>>>>> the
>>>>>> above given URL is made:
>>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>>> <inst:description
>>>>>> xmlns:inst="http://**installation.openoffice.org/**description<http://installation.openoffice.org/description>
>>>>>>
>>>>>> ">
>>>>>> </inst:description>
>>>>>>
>>>>>> Kay already made such an XML document available at:
>>>>>> http://www.openoffice.org/**ProductUpdateService/check.**Update<http://www.openoffice.org/ProductUpdateService/check.Update>
>>>>>>
>>>>>>
>>>>>> This response would allow the update functionality in AOO 3.4 to return
>>>>>> to
>>>>>> the user that the version is up to date.
>>>>>>
>>>>>> Thus, to reactivate an working update service for AOO 3.4 a redirection
>>>>>> is
>>>>>> needed.
>>>>>>
>>>>>>
>>>>> Are proposing that we just have a static XML file and redirect the
>>>>> requests so it loads that static file?
>>>>>
>>>>>
>>>> Yes, as a short-term and fast solution.
>>>>
>>>> I can see that as being a useful short-term solution. But soon we'll
>>>>> need some more complicated logic, right? For example, when we enable
>>>>> the 3.3. update check, we'll need to know that updates are available
>>>>> for some languages, but not others. Can we do that all with
>>>>> redirection to static files? Or do we need server-based logic, i.e.,
>>>>> a cgi script?
>>>>>
>>>>>
>>>> Static files would be possible, because each version has its own update
>>>> service
>>>> URL, but it would be not the best solution for the long-term.
>>>> Thus, some server-based logic would make sense.
>>>>
>>>> If we're going to need a cgi script in the end, I wonder if it makes
>>>>> sense to start with one now? We could have a simply script that today
>>>>> just always points to the "no update available" XML for AOO 3.4. But
>>>>> then we make it more complicated as we go.
>>>>>
>>>>>
>>>> I am currently in preparation of a proposal for an update service for OOo
>>>> 3.3
>>>> installations. Here, I can/will demonstrate how a server-based logic
>>>> would look
>>>> like.
>>>>
>>>> Can somebody make this happen?
>>>>>> I have to admit that do not have the knowledge to do it on my own.
>>>>>>
>>>>>>
>>>>> If we just redirect to a static file, I think you can just enter a
>>>>> JIRA request for Infra. If we go with a cgi script then we need
>>>>> someone to develop that script first.
>>>>>
>>>>>
>>>> If nobody objects, I would go for this short-term and static approach and
>>>> would
>>>> ask via JIRA request for Infra, if the redirect to the already existing
>>>> static
>>>> file can be established.
>>>>
>>>>
>>> I will use issue 119361 - https://issues.apache.org/ooo/**
>>> show_bug.cgi?id=119361<https://issues.apache.org/ooo/show_bug.cgi?id=119361>-
>>> to track the progress on this task.
>>>
>>> Best regards, Oliver.
>>>
>>
>>
>> OK, and a very short update on this.
>>
>> I tried to deal with this and continually ran into issues.
>>
>> At the simplest, I tired to make up a "generic" update for maybe all
>> platforms and languages that would just take them to a page to choose an
>> update -- basically our download/other.html at this point.
>>
>
> I think here some server-side script is needed.
> A complete "generic" solution which provides a "static" XML document is to hard
> figure out.
>
>> However, if you exclude the platform and other particulars in a very simple
>> XML file, nothing happens -- in other words, the URL is just ignored and
>> you get a "no updates" message. This is what is in:
>> /projects/update36/ProductUpdateService/check.update
>> now.
>
> That is right.
> The update functionality searches in the returned XML for its operating system
> and its architecture and a buildid which is greater than its own. If it does not
> found it, it assumes that no newer version is available.
>
>>
>> Also, life is complicated by appending the "pkgfmt " on update strings in
>>
>> <AOO install directory>/program/versionrc (for linux...name will vary
>> depending on OS)
>>
>
> I will do some further checks with the URL query part.
>
For a "static" solution the URL query part should not be a problem. It seems to
be completely neglected by the HTTP server.
I have currently some static test XML documents on
http://people.apache.org/~orw/testupdateservice/
The XML documents are included in the HTTP GET response regardless of the URL
query part.
As I am not an expert of HTTP and HTTP server, please correct me, if I am wrong
here.
Best regards, Oliver.
Re: [UPDATE SERVICE] proposal for a AOO 3.4 update service
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 16.05.2012 19:38, Kay Schenk wrote:
> On Tue, May 15, 2012 at 11:37 PM, Oliver-Rainer Wittmann<
> orwittmann@googlemail.com> wrote:
>
>> Hi,
>>
>>
>> On 15.05.2012 20:45, Oliver-Rainer Wittmann wrote:
>>
>>> Hi,
>>>
>>> Am 15.05.12 16:11, schrieb Rob Weir:
>>>
>>>> On Tue, May 15, 2012 at 8:11 AM, Oliver-Rainer Wittmann
>>>> <or...@googlemail.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> From my point of view it would make sense to reactivate a simple update
>>>>> service for AOO 3.4.
>>>>>
>>>>> The update URL for AOO 3.4 is:
>>>>> http://update38.services.**openoffice.org/**ProductUpdateService/check.
>>>>> **Update<http://update38.services.openoffice.org/ProductUpdateService/check.Update>
>>>>> (plus a query part ?pkgfmt=<pkgformat> for non-Windows platforms)
>>>>>
>>>>> As this URL resolves to nothing, the user currently gets the following
>>>>> response from the update functionality in AOO 3.4:
>>>>> Status: Checking for an update failed.
>>>>> Description: General Internet error has occurred.
>>>>>
>>>>> I propose provide the following XML document when a HTTP GET request to
>>>>> the
>>>>> above given URL is made:
>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>> <inst:description
>>>>> xmlns:inst="http://**installation.openoffice.org/**description<http://installation.openoffice.org/description>
>>>>> ">
>>>>> </inst:description>
>>>>>
>>>>> Kay already made such an XML document available at:
>>>>> http://www.openoffice.org/**ProductUpdateService/check.**Update<http://www.openoffice.org/ProductUpdateService/check.Update>
>>>>>
>>>>> This response would allow the update functionality in AOO 3.4 to return
>>>>> to
>>>>> the user that the version is up to date.
>>>>>
>>>>> Thus, to reactivate an working update service for AOO 3.4 a redirection
>>>>> is
>>>>> needed.
>>>>>
>>>>>
>>>> Are proposing that we just have a static XML file and redirect the
>>>> requests so it loads that static file?
>>>>
>>>>
>>> Yes, as a short-term and fast solution.
>>>
>>> I can see that as being a useful short-term solution. But soon we'll
>>>> need some more complicated logic, right? For example, when we enable
>>>> the 3.3. update check, we'll need to know that updates are available
>>>> for some languages, but not others. Can we do that all with
>>>> redirection to static files? Or do we need server-based logic, i.e.,
>>>> a cgi script?
>>>>
>>>>
>>> Static files would be possible, because each version has its own update
>>> service
>>> URL, but it would be not the best solution for the long-term.
>>> Thus, some server-based logic would make sense.
>>>
>>> If we're going to need a cgi script in the end, I wonder if it makes
>>>> sense to start with one now? We could have a simply script that today
>>>> just always points to the "no update available" XML for AOO 3.4. But
>>>> then we make it more complicated as we go.
>>>>
>>>>
>>> I am currently in preparation of a proposal for an update service for OOo
>>> 3.3
>>> installations. Here, I can/will demonstrate how a server-based logic
>>> would look
>>> like.
>>>
>>> Can somebody make this happen?
>>>>> I have to admit that do not have the knowledge to do it on my own.
>>>>>
>>>>>
>>>> If we just redirect to a static file, I think you can just enter a
>>>> JIRA request for Infra. If we go with a cgi script then we need
>>>> someone to develop that script first.
>>>>
>>>>
>>> If nobody objects, I would go for this short-term and static approach and
>>> would
>>> ask via JIRA request for Infra, if the redirect to the already existing
>>> static
>>> file can be established.
>>>
>>>
>> I will use issue 119361 - https://issues.apache.org/ooo/**
>> show_bug.cgi?id=119361<https://issues.apache.org/ooo/show_bug.cgi?id=119361>- to track the progress on this task.
>>
>> Best regards, Oliver.
>>
>
>
> OK, and a very short update on this.
>
> I tried to deal with this and continually ran into issues.
>
> At the simplest, I tired to make up a "generic" update for maybe all
> platforms and languages that would just take them to a page to choose an
> update -- basically our download/other.html at this point.
>
I think here some server-side script is needed.
A complete "generic" solution which provides a "static" XML document is to hard
figure out.
> However, if you exclude the platform and other particulars in a very simple
> XML file, nothing happens -- in other words, the URL is just ignored and
> you get a "no updates" message. This is what is in:
> /projects/update36/ProductUpdateService/check.update
> now.
That is right.
The update functionality searches in the returned XML for its operating system
and its architecture and a buildid which is greater than its own. If it does not
found it, it assumes that no newer version is available.
>
> Also, life is complicated by appending the "pkgfmt " on update strings in
>
> <AOO install directory>/program/versionrc (for linux...name will vary
> depending on OS)
>
I will do some further checks with the URL query part.
> Finally, whatever we do...assuming we can get a feed to work...under NO
> circumstance should we redirect update30.services.openoffice.org to the
> "dummy" host. The older version 3.0 did something entirely different, and
> when I had infra do this redirect some months ago, it caused the Apache
> webserver complex to crash.
>
> I *thing* the newer services update32, update33, update35, etc. will be
> fine, but we need to verify this.
>
Please let us continue possible update services for former versions in my other
proposal thread.
Best regards, Oliver.
Re: [UPDATE SERVICE] proposal for a AOO 3.4 update service
Posted by Kay Schenk <ka...@gmail.com>.
On Tue, May 15, 2012 at 11:37 PM, Oliver-Rainer Wittmann <
orwittmann@googlemail.com> wrote:
> Hi,
>
>
> On 15.05.2012 20:45, Oliver-Rainer Wittmann wrote:
>
>> Hi,
>>
>> Am 15.05.12 16:11, schrieb Rob Weir:
>>
>>> On Tue, May 15, 2012 at 8:11 AM, Oliver-Rainer Wittmann
>>> <or...@googlemail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> From my point of view it would make sense to reactivate a simple update
>>>> service for AOO 3.4.
>>>>
>>>> The update URL for AOO 3.4 is:
>>>> http://update38.services.**openoffice.org/**ProductUpdateService/check.
>>>> **Update<http://update38.services.openoffice.org/ProductUpdateService/check.Update>
>>>> (plus a query part ?pkgfmt=<pkgformat> for non-Windows platforms)
>>>>
>>>> As this URL resolves to nothing, the user currently gets the following
>>>> response from the update functionality in AOO 3.4:
>>>> Status: Checking for an update failed.
>>>> Description: General Internet error has occurred.
>>>>
>>>> I propose provide the following XML document when a HTTP GET request to
>>>> the
>>>> above given URL is made:
>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>> <inst:description
>>>> xmlns:inst="http://**installation.openoffice.org/**description<http://installation.openoffice.org/description>
>>>> ">
>>>> </inst:description>
>>>>
>>>> Kay already made such an XML document available at:
>>>> http://www.openoffice.org/**ProductUpdateService/check.**Update<http://www.openoffice.org/ProductUpdateService/check.Update>
>>>>
>>>> This response would allow the update functionality in AOO 3.4 to return
>>>> to
>>>> the user that the version is up to date.
>>>>
>>>> Thus, to reactivate an working update service for AOO 3.4 a redirection
>>>> is
>>>> needed.
>>>>
>>>>
>>> Are proposing that we just have a static XML file and redirect the
>>> requests so it loads that static file?
>>>
>>>
>> Yes, as a short-term and fast solution.
>>
>> I can see that as being a useful short-term solution. But soon we'll
>>> need some more complicated logic, right? For example, when we enable
>>> the 3.3. update check, we'll need to know that updates are available
>>> for some languages, but not others. Can we do that all with
>>> redirection to static files? Or do we need server-based logic, i.e.,
>>> a cgi script?
>>>
>>>
>> Static files would be possible, because each version has its own update
>> service
>> URL, but it would be not the best solution for the long-term.
>> Thus, some server-based logic would make sense.
>>
>> If we're going to need a cgi script in the end, I wonder if it makes
>>> sense to start with one now? We could have a simply script that today
>>> just always points to the "no update available" XML for AOO 3.4. But
>>> then we make it more complicated as we go.
>>>
>>>
>> I am currently in preparation of a proposal for an update service for OOo
>> 3.3
>> installations. Here, I can/will demonstrate how a server-based logic
>> would look
>> like.
>>
>> Can somebody make this happen?
>>>> I have to admit that do not have the knowledge to do it on my own.
>>>>
>>>>
>>> If we just redirect to a static file, I think you can just enter a
>>> JIRA request for Infra. If we go with a cgi script then we need
>>> someone to develop that script first.
>>>
>>>
>> If nobody objects, I would go for this short-term and static approach and
>> would
>> ask via JIRA request for Infra, if the redirect to the already existing
>> static
>> file can be established.
>>
>>
> I will use issue 119361 - https://issues.apache.org/ooo/**
> show_bug.cgi?id=119361<https://issues.apache.org/ooo/show_bug.cgi?id=119361>- to track the progress on this task.
>
> Best regards, Oliver.
>
OK, and a very short update on this.
I tried to deal with this and continually ran into issues.
At the simplest, I tired to make up a "generic" update for maybe all
platforms and languages that would just take them to a page to choose an
update -- basically our download/other.html at this point.
However, if you exclude the platform and other particulars in a very simple
XML file, nothing happens -- in other words, the URL is just ignored and
you get a "no updates" message. This is what is in:
/projects/update36/ProductUpdateService/check.update
now.
Also, life is complicated by appending the "pkgfmt " on update strings in
<AOO install directory>/program/versionrc (for linux...name will vary
depending on OS)
Finally, whatever we do...assuming we can get a feed to work...under NO
circumstance should we redirect update30.services.openoffice.org to the
"dummy" host. The older version 3.0 did something entirely different, and
when I had infra do this redirect some months ago, it caused the Apache
webserver complex to crash.
I *thing* the newer services update32, update33, update35, etc. will be
fine, but we need to verify this.
--
----------------------------------------------------------------------------------------
MzK
"Well, life has a funny way of sneaking up on you
And life has a funny way of helping you out
Helping you out."
-- "Ironic", Alanis Morissette
Re: [UPDATE SERVICE] proposal for a AOO 3.4 update service
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 15.05.2012 20:45, Oliver-Rainer Wittmann wrote:
> Hi,
>
> Am 15.05.12 16:11, schrieb Rob Weir:
>> On Tue, May 15, 2012 at 8:11 AM, Oliver-Rainer Wittmann
>> <or...@googlemail.com> wrote:
>>> Hi,
>>>
>>> From my point of view it would make sense to reactivate a simple update
>>> service for AOO 3.4.
>>>
>>> The update URL for AOO 3.4 is:
>>> http://update38.services.openoffice.org/ProductUpdateService/check.Update
>>> (plus a query part ?pkgfmt=<pkgformat> for non-Windows platforms)
>>>
>>> As this URL resolves to nothing, the user currently gets the following
>>> response from the update functionality in AOO 3.4:
>>> Status: Checking for an update failed.
>>> Description: General Internet error has occurred.
>>>
>>> I propose provide the following XML document when a HTTP GET request to the
>>> above given URL is made:
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <inst:description
>>> xmlns:inst="http://installation.openoffice.org/description">
>>> </inst:description>
>>>
>>> Kay already made such an XML document available at:
>>> http://www.openoffice.org/ProductUpdateService/check.Update
>>>
>>> This response would allow the update functionality in AOO 3.4 to return to
>>> the user that the version is up to date.
>>>
>>> Thus, to reactivate an working update service for AOO 3.4 a redirection is
>>> needed.
>>>
>>
>> Are proposing that we just have a static XML file and redirect the
>> requests so it loads that static file?
>>
>
> Yes, as a short-term and fast solution.
>
>> I can see that as being a useful short-term solution. But soon we'll
>> need some more complicated logic, right? For example, when we enable
>> the 3.3. update check, we'll need to know that updates are available
>> for some languages, but not others. Can we do that all with
>> redirection to static files? Or do we need server-based logic, i.e.,
>> a cgi script?
>>
>
> Static files would be possible, because each version has its own update service
> URL, but it would be not the best solution for the long-term.
> Thus, some server-based logic would make sense.
>
>> If we're going to need a cgi script in the end, I wonder if it makes
>> sense to start with one now? We could have a simply script that today
>> just always points to the "no update available" XML for AOO 3.4. But
>> then we make it more complicated as we go.
>>
>
> I am currently in preparation of a proposal for an update service for OOo 3.3
> installations. Here, I can/will demonstrate how a server-based logic would look
> like.
>
>>> Can somebody make this happen?
>>> I have to admit that do not have the knowledge to do it on my own.
>>>
>>
>> If we just redirect to a static file, I think you can just enter a
>> JIRA request for Infra. If we go with a cgi script then we need
>> someone to develop that script first.
>>
>
> If nobody objects, I would go for this short-term and static approach and would
> ask via JIRA request for Infra, if the redirect to the already existing static
> file can be established.
>
I will use issue 119361 - https://issues.apache.org/ooo/show_bug.cgi?id=119361 -
to track the progress on this task.
Best regards, Oliver.
Re: [UPDATE SERVICE] proposal for a AOO 3.4 update service
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
Am 15.05.12 16:11, schrieb Rob Weir:
> On Tue, May 15, 2012 at 8:11 AM, Oliver-Rainer Wittmann
> <or...@googlemail.com> wrote:
>> Hi,
>>
>> From my point of view it would make sense to reactivate a simple update
>> service for AOO 3.4.
>>
>> The update URL for AOO 3.4 is:
>> http://update38.services.openoffice.org/ProductUpdateService/check.Update
>> (plus a query part ?pkgfmt=<pkgformat> for non-Windows platforms)
>>
>> As this URL resolves to nothing, the user currently gets the following
>> response from the update functionality in AOO 3.4:
>> Status: Checking for an update failed.
>> Description: General Internet error has occurred.
>>
>> I propose provide the following XML document when a HTTP GET request to the
>> above given URL is made:
>> <?xml version="1.0" encoding="UTF-8"?>
>> <inst:description
>> xmlns:inst="http://installation.openoffice.org/description">
>> </inst:description>
>>
>> Kay already made such an XML document available at:
>> http://www.openoffice.org/ProductUpdateService/check.Update
>>
>> This response would allow the update functionality in AOO 3.4 to return to
>> the user that the version is up to date.
>>
>> Thus, to reactivate an working update service for AOO 3.4 a redirection is
>> needed.
>>
>
> Are proposing that we just have a static XML file and redirect the
> requests so it loads that static file?
>
Yes, as a short-term and fast solution.
> I can see that as being a useful short-term solution. But soon we'll
> need some more complicated logic, right? For example, when we enable
> the 3.3. update check, we'll need to know that updates are available
> for some languages, but not others. Can we do that all with
> redirection to static files? Or do we need server-based logic, i.e.,
> a cgi script?
>
Static files would be possible, because each version has its own update
service URL, but it would be not the best solution for the long-term.
Thus, some server-based logic would make sense.
> If we're going to need a cgi script in the end, I wonder if it makes
> sense to start with one now? We could have a simply script that today
> just always points to the "no update available" XML for AOO 3.4. But
> then we make it more complicated as we go.
>
I am currently in preparation of a proposal for an update service for
OOo 3.3 installations. Here, I can/will demonstrate how a server-based
logic would look like.
>> Can somebody make this happen?
>> I have to admit that do not have the knowledge to do it on my own.
>>
>
> If we just redirect to a static file, I think you can just enter a
> JIRA request for Infra. If we go with a cgi script then we need
> someone to develop that script first.
>
If nobody objects, I would go for this short-term and static approach
and would ask via JIRA request for Infra, if the redirect to the already
existing static file can be established.
Best regards, Oliver.
Re: [UPDATE SERVICE] proposal for a AOO 3.4 update service
Posted by Rob Weir <ro...@apache.org>.
On Tue, May 15, 2012 at 8:11 AM, Oliver-Rainer Wittmann
<or...@googlemail.com> wrote:
> Hi,
>
> From my point of view it would make sense to reactivate a simple update
> service for AOO 3.4.
>
> The update URL for AOO 3.4 is:
> http://update38.services.openoffice.org/ProductUpdateService/check.Update
> (plus a query part ?pkgfmt=<pkgformat> for non-Windows platforms)
>
> As this URL resolves to nothing, the user currently gets the following
> response from the update functionality in AOO 3.4:
> Status: Checking for an update failed.
> Description: General Internet error has occurred.
>
> I propose provide the following XML document when a HTTP GET request to the
> above given URL is made:
> <?xml version="1.0" encoding="UTF-8"?>
> <inst:description
> xmlns:inst="http://installation.openoffice.org/description">
> </inst:description>
>
> Kay already made such an XML document available at:
> http://www.openoffice.org/ProductUpdateService/check.Update
>
> This response would allow the update functionality in AOO 3.4 to return to
> the user that the version is up to date.
>
> Thus, to reactivate an working update service for AOO 3.4 a redirection is
> needed.
>
Are proposing that we just have a static XML file and redirect the
requests so it loads that static file?
I can see that as being a useful short-term solution. But soon we'll
need some more complicated logic, right? For example, when we enable
the 3.3. update check, we'll need to know that updates are available
for some languages, but not others. Can we do that all with
redirection to static files? Or do we need server-based logic, i.e.,
a cgi script?
If we're going to need a cgi script in the end, I wonder if it makes
sense to start with one now? We could have a simply script that today
just always points to the "no update available" XML for AOO 3.4. But
then we make it more complicated as we go.
> Can somebody make this happen?
> I have to admit that do not have the knowledge to do it on my own.
>
If we just redirect to a static file, I think you can just enter a
JIRA request for Infra. If we go with a cgi script then we need
someone to develop that script first.
-Rob
>
> Best regards, Oliver.
Re: [UPDATE SERVICE] proposal for a AOO 3.4 update service
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 15.05.2012 21:03, Andrea Pescetti wrote:
> Oliver-Rainer Wittmann wrote:
>> The update URL for AOO 3.4 is:
>> http://update38.services.openoffice.org/ProductUpdateService/check.Update (plus
>> a query part ?pkgfmt=<pkgformat> for non-Windows platforms)
>
> Which leaves me wondering... What URL is OpenOffice.org 3.4 beta (the one from
> April 2011) using? If it is the same, then it isn't 100% correct to say that no
> updates are available. However, 3.4-beta is not a stable release and its
> installed base will become negligible compared to 3.4 very soon, so I definitely
> support setting up a dummy update service (at least, to avoid that users of 3.4
> get an error message).
>
As far as I can see, my OOo 3.4 Beta installation on my Windows 7 machine has
the same Update URL as the final released AOO 3.4.
Thus, these installations will not be considered. But, I think that the people
who had installed this version are probably active enough to be aware of our AOO
3.4 release.
Best regards, Oliver.
Re: [UPDATE SERVICE] proposal for a AOO 3.4 update service
Posted by Andrea Pescetti <pe...@apache.org>.
Oliver-Rainer Wittmann wrote:
> The update URL for AOO 3.4 is:
> http://update38.services.openoffice.org/ProductUpdateService/check.Update (plus
> a query part ?pkgfmt=<pkgformat> for non-Windows platforms)
Which leaves me wondering... What URL is OpenOffice.org 3.4 beta (the
one from April 2011) using? If it is the same, then it isn't 100%
correct to say that no updates are available. However, 3.4-beta is not a
stable release and its installed base will become negligible compared to
3.4 very soon, so I definitely support setting up a dummy update service
(at least, to avoid that users of 3.4 get an error message).
Regards,
Andrea.
Re: [UPDATE SERVICE] proposal for a AOO 3.4 update service
Posted by Paulo de Souza Lima <pa...@varekai.org>.
2012/5/15 Oliver-Rainer Wittmann <or...@googlemail.com>
> Hi,
>
> From my point of view it would make sense to reactivate a simple update
> service for AOO 3.4.
>
> The update URL for AOO 3.4 is:
> http://update38.services.**openoffice.org/**ProductUpdateService/check.**
> Update<http://update38.services.openoffice.org/ProductUpdateService/check.Update>(plus a query part ?pkgfmt=<pkgformat> for non-Windows platforms)
>
> As this URL resolves to nothing, the user currently gets the following
> response from the update functionality in AOO 3.4:
> Status: Checking for an update failed.
> Description: General Internet error has occurred.
>
> I propose provide the following XML document when a HTTP GET request to
> the above given URL is made:
> <?xml version="1.0" encoding="UTF-8"?>
> <inst:description xmlns:inst="http://**installation.openoffice.org/**
> description <http://installation.openoffice.org/description>">
> </inst:description>
>
> Kay already made such an XML document available at:
> http://www.openoffice.org/**ProductUpdateService/check.**Update<http://www.openoffice.org/ProductUpdateService/check.Update>
>
> This response would allow the update functionality in AOO 3.4 to return to
> the user that the version is up to date.
>
> Thus, to reactivate an working update service for AOO 3.4 a redirection is
> needed.
>
> Can somebody make this happen?
> I have to admit that do not have the knowledge to do it on my own.
>
>
> Best regards, Oliver.
>
Hi!
This feature would be pretty good!!
--
Paulo de Souza Lima
http://almalivre.wordpress.com
Curitiba - PR
Linux User #432358
Ubuntu User #28729