Re: [UPDATE SERVICE] proposal for a AOO 3.4 update service
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: [HEADS UP] Re: [UPDATE SERVICE] proposal for a AOO 3.4 update service
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
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
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
On Tue, 22 May 2012 10:28:15 +0200 Andrea Pescetti pesce...@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 ofarr...@iol.ie
Re: [HEADS UP] Re: [UPDATE SERVICE] proposal for a AOO 3.4 update service
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
2012/5/22 Oliver-Rainer Wittmann orwittm...@googlemail.com Hi, On 22.05.2012 10:35, Rory O'Farrell wrote: On Tue, 22 May 2012 10:28:15 +0200 Andrea Pescettipesce...@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
2012/5/22 Paulo de Souza Lima paulo.s.l...@varekai.org 2012/5/22 Oliver-Rainer Wittmann orwittm...@googlemail.com Hi, On 22.05.2012 10:35, Rory O'Farrell wrote: On Tue, 22 May 2012 10:28:15 +0200 Andrea Pescettipesce...@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
Hi, On 22.05.2012 14:47, Paulo de Souza Lima wrote: 2012/5/22 Oliver-Rainer Wittmannorwittm...@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
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 Wittmannorwittm...@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
2012/5/22 Oliver-Rainer Wittmann orwittm...@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 Wittmannorwittmann@**googlemail.comorwittm...@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.**Updatehttp://update38.services.openoffice.org/ProductUpdateService/check.Update, the second to http://openoffice.org/**projects/update38/** ProductUpdateService/check.**Updatehttp://openoffice.org/projects/update38/ProductUpdateService/check.Updateand the final one to http://www.openoffice.org/**projects/update38/** ProductUpdateService/check.**Updatehttp://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
Am Dienstag, 22. Mai 2012 um 15:53 schrieb Paulo de Souza Lima: 2012/5/22 Oliver-Rainer Wittmann orwittm...@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 Wittmannorwittmann@**googlemail.comorwittm...@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.**Updatehttp://update38.services.openoffice.org/ProductUpdateService/check.Update, the second to http://openoffice.org/**projects/update38/** ProductUpdateService/check.**Updatehttp://openoffice.org/projects/update38/ProductUpdateService/check.Updateand the final one to http://www.openoffice.org/**projects/update38/** ProductUpdateService/check.**Updatehttp://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
2012/5/22 Juergen Schmidt jogischm...@googlemail.com Am Dienstag, 22. Mai 2012 um 15:53 schrieb Paulo de Souza Lima: 2012/5/22 Oliver-Rainer Wittmann orwittm...@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 Wittmannorwittmann@**googlemail.com orwittm...@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.Updateand 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: [UPDATE SERVICE] proposal for a AOO 3.4 update service
Hi Roberto, On 18.05.2012 19:14, Roberto Galoppini wrote: On Wed, May 16, 2012 at 9:26 PM, Rob Weirrobw...@apache.org wrote: On Wed, May 16, 2012 at 3:16 PM, Oliver-Rainer Wittmann orwittm...@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 orwittm...@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 orwittm...@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
Re: [UPDATE SERVICE] proposal for a AOO 3.4 update service
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 orwittm...@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
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
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 orwittm...@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.
[HEADS UP] Re: [UPDATE SERVICE] proposal for a AOO 3.4 update service
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 orwittm...@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
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 orwittm...@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
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
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: [UPDATE SERVICE] proposal for a AOO 3.4 update service
On Mon, May 21, 2012 at 1:43 PM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi Roberto, On 18.05.2012 19:14, Roberto Galoppini wrote: On Wed, May 16, 2012 at 9:26 PM, Rob Weirrobw...@apache.org wrote: On Wed, May 16, 2012 at 3:16 PM, Oliver-Rainer Wittmann orwittm...@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 orwittm...@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 orwittm...@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
Re: [UPDATE SERVICE] proposal for a AOO 3.4 update service
On Wed, May 16, 2012 at 9:26 PM, Rob Weir robw...@apache.org wrote: On Wed, May 16, 2012 at 3:16 PM, Oliver-Rainer Wittmann orwittm...@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 orwittm...@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 orwittm...@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
Re: [UPDATE SERVICE] proposal for a AOO 3.4 update service
On Wed, May 16, 2012 at 12:26 PM, Rob Weir robw...@apache.org wrote: On Wed, May 16, 2012 at 3:16 PM, Oliver-Rainer Wittmann orwittm...@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 orwittm...@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 orwittm...@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
Re: [UPDATE SERVICE] proposal for a AOO 3.4 update service
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 orwittm...@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
On Tue, May 15, 2012 at 11:37 PM, Oliver-Rainer Wittmann orwittm...@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 orwittm...@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. **Updatehttp://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/**descriptionhttp://installation.openoffice.org/description /inst:description Kay already made such an XML document available at: http://www.openoffice.org/**ProductUpdateService/check.**Updatehttp://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=119361https://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
Hi, On 16.05.2012 19:38, Kay Schenk wrote: On Tue, May 15, 2012 at 11:37 PM, Oliver-Rainer Wittmann orwittm...@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 orwittm...@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. **Updatehttp://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/**descriptionhttp://installation.openoffice.org/description /inst:description Kay already made such an XML document available at: http://www.openoffice.org/**ProductUpdateService/check.**Updatehttp://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=119361https://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
Re: [UPDATE SERVICE] proposal for a AOO 3.4 update service
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 orwittm...@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 orwittm...@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. **Updatehttp://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/**descriptionhttp://installation.openoffice.org/description /inst:description Kay already made such an XML document available at: http://www.openoffice.org/**ProductUpdateService/check.**Updatehttp://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=119361https://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
On Wed, May 16, 2012 at 3:16 PM, Oliver-Rainer Wittmann orwittm...@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 orwittm...@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 orwittm...@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. **Updatehttp://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/**descriptionhttp://installation.openoffice.org/description /inst:description Kay already made such an XML document available at: http://www.openoffice.org/**ProductUpdateService/check.**Updatehttp://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=119361https://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
[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: [UPDATE SERVICE] proposal for a AOO 3.4 update service
On Tue, May 15, 2012 at 8:11 AM, Oliver-Rainer Wittmann orwittm...@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
Hi, Am 15.05.12 16:11, schrieb Rob Weir: On Tue, May 15, 2012 at 8:11 AM, Oliver-Rainer Wittmann orwittm...@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
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.