Re: update service - proposal for temporary solution until AOO 3.4 is released.
Hi,
On 21.03.2012 00:33, Kay Schenk wrote:
On Tue, Mar 20, 2012 at 2:36 PM, Kay Schenkkay.sch...@gmail.com wrote:
On Tue, Mar 20, 2012 at 10:01 AM, Dave Fisherdave2w...@comcast.netwrote:
On Mar 20, 2012, at 9:45 AM, Kay Schenk wrote:
On Mon, Mar 19, 2012 at 5:31 PM, Ariel Constenla-Haile
arie...@apache.orgwrote:
Hi Kay,
On Mon, Mar 19, 2012 at 03:42:22PM -0700, Kay Schenk wrote:
Well interesting...I did some editing of versionrc and now I get that
an
update does not exist after pulling off the pkgfmt=rpm requirement.
However, we can not expect users of existing product to go messing
with
their existing setups (i.e. editing files). I don't mind the odd
message
I
was getting before about an rpm package not being found.
I'm just wondering if there's some way to configure the snippet you
sent
to
just do something a bit more friendly for all possible situations that
are
currently out there now.
Thoughts? Any experts on how to create a generic null feed?
I tried with my original empty xml file (not a feed) and it works as
expected with every combination:
UpdateURL=
http://people.apache.org/~arielch/ProductUpdateService/check.Update
UpdateURL=
http://people.apache.org/~arielch/ProductUpdateService/check.Update?pkgfmt=rpm
UpdateURL=
http://people.apache.org/~arielch/ProductUpdateService/check.Update?pkgfmt=deb
UpdateURL=
http://people.apache.org/~arielch/ProductUpdateService/check.Update?pkgfmt=dmg
I can't see why it does not work for you.
Please try pointing the UpdateURL to this file
http://people.apache.org/~arielch/ProductUpdateService/check.Update
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Well, foo, when I do this replacement, it does work as you say! Darn!
OK,
let me re-investigate why the other snippet with my internal host
redirect
isn't working quite right! :(
How are doing this redirect?
Regards,
Dave
I've got the following in my local /etc/hosts
140.211.11.131 update36.services.openoffice.org
here are versions I've played with in versionrc (I split the lines for
easier reading for you)
+
[Version]
AllLanguages=en-US
buildid=330m20(Build:9567)
ExtensionUpdateURL=
http://updateexte.services.openoffice.org/ExtensionUpdateService/check.Update
OOOBaseVersion=3.3
ProductBuildid=9567
ProductMajor=330
ProductMinor=20
ProductSource=OOO330
UpdateID=OpenOffice.org_3_en-US
#UpdateURL=
http://update36.services.openoffice.org/ProductUpdateService/check.Update?pkgfmt=rpm
UpdateURL=
http://update36.services.openoffice.org/ProductUpdateService/check.Update
#UpdateURL=
http://people.apache.org/~arielch/ProductUpdateService/check.Update?pkgfmt=rpm
UpdateUserAgent=PRODUCT (${buildid}; ${_OS}; ${_ARCH};
BundledLanguages=${AllLanguages})
++
using Ariel's returns no update. Using the current one with the redirect
returns the error business. (i mean it connects but I get a different
message, a failed...)
Things of note vis a vis people.apache.org vs www.openoffice.org (where I
have the current re-route)
If you just bring up:
http://www.openoffice.org/ProductUpdateService/check.Update
vs
http://people.apache.org/~arielch/ProductUpdateService/check.Update
they look different in my browser...one has UTF-8 vs utf-8
so I'm curious about this. I did up a little cgi and ran it on both
people.apache.org and well, ooo-site-staging.apache.org and they both
produce the same environment info. So ???
http://people.apache.org/~kschenk/cgi-bin/env.cgi
http://ooo-site.staging.apache.org/cgi-bin/env.cgi
I will change the UTF-8 to utf-8 on www.openoffice.org and see what
happens. Also did a diff on them and nothing but the case business.
Meanwhile -- do you know how we get cgi to run on www.openoffice.org? I
see we have a directory for this. I dumped some test scripts in it, but
www.openoffice.org/cgi-bin/h.cgi (Hello World) preoduces nothing. :(
If not, I will get in touch with INFRA.
a final note on this...if I directly put
UpdateURL=http://www.openoffice.org/ProductUpdateService/check.Updatehttp://people.apache.org/%7Earielch/ProductUpdateService/check.Update?pkgfmt=rpm
in my versionrc file, it works per Ariel's comments -- 'No Update
Available.
However, my redirect via /etc/hosts causes the weird result. So maybe
something is not quite right with this (???)
It looks like your local 'redirection' does not work.
You can check your 'redirection' in your browser.
On my system (Windows 7) I observe the following:
- browsing to www.openoffice.org/ProductUpdateService/check.Update using FireFox
shows me the XML snippet.
- a ping to www.openoffice.org reveals IP address 140.211.11.131.
- browsing to 140.211.11.131/ProductUpdateService/check.Update using FireFox
return 404 Not Found.
- browsing to 140.211.11.311 using FireFox shows ASF main page.
- adapting my ...\etc\hosts file as you have done and browsing to
Re: update service - proposal for temporary solution until AOO 3.4 is released.
Hi, On 21.03.2012 09:48, Oliver-Rainer Wittmann wrote: [snip...] a final note on this...if I directly put UpdateURL=http://www.openoffice.org/ProductUpdateService/check.Updatehttp://people.apache.org/%7Earielch/ProductUpdateService/check.Update?pkgfmt=rpm in my versionrc file, it works per Ariel's comments -- 'No Update Available. However, my redirect via /etc/hosts causes the weird result. So maybe something is not quite right with this (???) It looks like your local 'redirection' does not work. You can check your 'redirection' in your browser. On my system (Windows 7) I observe the following: - browsing to www.openoffice.org/ProductUpdateService/check.Update using FireFox shows me the XML snippet. - a ping to www.openoffice.org reveals IP address 140.211.11.131. - browsing to 140.211.11.131/ProductUpdateService/check.Update using FireFox return 404 Not Found. - browsing to 140.211.11.311 using FireFox shows ASF main page. - adapting my ...\etc\hosts file as you have done and browsing to update36.services.openoffice.org/ProductUpdateService/check.Update using FireFox results in a connection time stating the standard message which is headed by The connection was reset - the same you got when you browse to a non-existing server - reverting the change to my ...\etc\hosts and performing a ping to update36.services.openoffice.org outputs the following: output $ ping update36.services.openoffice.org Pinging sd-web2.staroffice.de [192.18.197.109] with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for 192.18.197.109: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), /output BTW, the used HTTP/WebDAV client library and its integration into our UCB is able to handle HTTP redirects which are typically triggered by return HTTP status code 301 - HTTP status codes 302, 303 and 307 are also handled. Best regards, Oliver.
Re: update service - proposal for temporary solution until AOO 3.4 is released.
On Wed, Mar 21, 2012 at 1:48 AM, Oliver-Rainer Wittmann
orwittm...@googlemail.com wrote:
Hi,
On 21.03.2012 00:33, Kay Schenk wrote:
On Tue, Mar 20, 2012 at 2:36 PM, Kay Schenkkay.sch...@gmail.com wrote:
On Tue, Mar 20, 2012 at 10:01 AM, Dave Fisherdave2w...@comcast.net**
wrote:
On Mar 20, 2012, at 9:45 AM, Kay Schenk wrote:
On Mon, Mar 19, 2012 at 5:31 PM, Ariel Constenla-Haile
arie...@apache.orgwrote:
Hi Kay,
On Mon, Mar 19, 2012 at 03:42:22PM -0700, Kay Schenk wrote:
Well interesting...I did some editing of versionrc and now I get that
an
update does not exist after pulling off the pkgfmt=rpm requirement.
However, we can not expect users of existing product to go messing
with
their existing setups (i.e. editing files). I don't mind the odd
message
I
was getting before about an rpm package not being found.
I'm just wondering if there's some way to configure the snippet you
sent
to
just do something a bit more friendly for all possible situations
that
are
currently out there now.
Thoughts? Any experts on how to create a generic null feed?
I tried with my original empty xml file (not a feed) and it works as
expected with every combination:
UpdateURL=
http://people.apache.org/~**arielch/ProductUpdateService/**
check.Updatehttp://people.apache.org/%7Earielch/ProductUpdateService/check.Update
UpdateURL=
http://people.apache.org/~**arielch/ProductUpdateService/**
check.Update?pkgfmt=rpmhttp://people.apache.org/%7Earielch/ProductUpdateService/check.Update?pkgfmt=rpm
UpdateURL=
http://people.apache.org/~**arielch/ProductUpdateService/**
check.Update?pkgfmt=debhttp://people.apache.org/%7Earielch/ProductUpdateService/check.Update?pkgfmt=deb
UpdateURL=
http://people.apache.org/~**arielch/ProductUpdateService/**
check.Update?pkgfmt=dmghttp://people.apache.org/%7Earielch/ProductUpdateService/check.Update?pkgfmt=dmg
I can't see why it does not work for you.
Please try pointing the UpdateURL to this file
http://people.apache.org/~**arielch/ProductUpdateService/**
check.Updatehttp://people.apache.org/%7Earielch/ProductUpdateService/check.Update
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Well, foo, when I do this replacement, it does work as you say! Darn!
OK,
let me re-investigate why the other snippet with my internal host
redirect
isn't working quite right! :(
How are doing this redirect?
Regards,
Dave
I've got the following in my local /etc/hosts
140.211.11.131
update36.services.openoffice.**orghttp://update36.services.openoffice.org
here are versions I've played with in versionrc (I split the lines for
easier reading for you)
++**+++
[Version]
AllLanguages=en-US
buildid=330m20(Build:9567)
ExtensionUpdateURL=
http://updateexte.services.**openoffice.org/**
ExtensionUpdateService/check.**Updatehttp://updateexte.services.openoffice.org/ExtensionUpdateService/check.Update
OOOBaseVersion=3.3
ProductBuildid=9567
ProductMajor=330
ProductMinor=20
ProductSource=OOO330
UpdateID=OpenOffice.org_3_en-**US
#UpdateURL=
http://update36.services.**openoffice.org/**ProductUpdateService/check.*
*Update?pkgfmt=rpmhttp://update36.services.openoffice.org/ProductUpdateService/check.Update?pkgfmt=rpm
UpdateURL=
http://update36.services.**openoffice.org/**ProductUpdateService/check.*
*Updatehttp://update36.services.openoffice.org/ProductUpdateService/check.Update
#UpdateURL=
http://people.apache.org/~**arielch/ProductUpdateService/**
check.Update?pkgfmt=rpmhttp://people.apache.org/%7Earielch/ProductUpdateService/check.Update?pkgfmt=rpm
UpdateUserAgent=PRODUCT (${buildid}; ${_OS}; ${_ARCH};
BundledLanguages=${**AllLanguages})
++**
using Ariel's returns no update. Using the current one with the
redirect
returns the error business. (i mean it connects but I get a different
message, a failed...)
Things of note vis a vis people.apache.org vs www.openoffice.org (where
I
have the current re-route)
If you just bring up:
http://www.openoffice.org/**ProductUpdateService/check.**Updatehttp://www.openoffice.org/ProductUpdateService/check.Update
vs
http://people.apache.org/~**arielch/ProductUpdateService/**check.Updatehttp://people.apache.org/%7Earielch/ProductUpdateService/check.Update
they look different in my browser...one has UTF-8 vs utf-8
so I'm curious about this. I did up a little cgi and ran it on both
people.apache.org and well, ooo-site-staging.apache.org and they both
produce the same environment info. So ???
http://people.apache.org/~**kschenk/cgi-bin/env.cgihttp://people.apache.org/%7Ekschenk/cgi-bin/env.cgi
http://ooo-site.staging.**apache.org/cgi-bin/env.cgihttp://ooo-site.staging.apache.org/cgi-bin/env.cgi
I will change the UTF-8 to utf-8 on www.openoffice.org and see what
happens. Also did a diff on them and nothing but the case business.
Meanwhile -- do you know how we get cgi to
Re: update service - proposal for temporary solution until AOO 3.4 is released.
On Mar 21, 2012, at 9:09 AM, Kay Schenk wrote:
On Wed, Mar 21, 2012 at 1:48 AM, Oliver-Rainer Wittmann
orwittm...@googlemail.com wrote:
Hi,
On 21.03.2012 00:33, Kay Schenk wrote:
On Tue, Mar 20, 2012 at 2:36 PM, Kay Schenkkay.sch...@gmail.com wrote:
On Tue, Mar 20, 2012 at 10:01 AM, Dave Fisherdave2w...@comcast.net**
wrote:
On Mar 20, 2012, at 9:45 AM, Kay Schenk wrote:
On Mon, Mar 19, 2012 at 5:31 PM, Ariel Constenla-Haile
arie...@apache.orgwrote:
Hi Kay,
On Mon, Mar 19, 2012 at 03:42:22PM -0700, Kay Schenk wrote:
Well interesting...I did some editing of versionrc and now I get that
an
update does not exist after pulling off the pkgfmt=rpm requirement.
However, we can not expect users of existing product to go messing
with
their existing setups (i.e. editing files). I don't mind the odd
message
I
was getting before about an rpm package not being found.
I'm just wondering if there's some way to configure the snippet you
sent
to
just do something a bit more friendly for all possible situations
that
are
currently out there now.
Thoughts? Any experts on how to create a generic null feed?
I tried with my original empty xml file (not a feed) and it works as
expected with every combination:
UpdateURL=
http://people.apache.org/~**arielch/ProductUpdateService/**
check.Updatehttp://people.apache.org/%7Earielch/ProductUpdateService/check.Update
UpdateURL=
http://people.apache.org/~**arielch/ProductUpdateService/**
check.Update?pkgfmt=rpmhttp://people.apache.org/%7Earielch/ProductUpdateService/check.Update?pkgfmt=rpm
UpdateURL=
http://people.apache.org/~**arielch/ProductUpdateService/**
check.Update?pkgfmt=debhttp://people.apache.org/%7Earielch/ProductUpdateService/check.Update?pkgfmt=deb
UpdateURL=
http://people.apache.org/~**arielch/ProductUpdateService/**
check.Update?pkgfmt=dmghttp://people.apache.org/%7Earielch/ProductUpdateService/check.Update?pkgfmt=dmg
I can't see why it does not work for you.
Please try pointing the UpdateURL to this file
http://people.apache.org/~**arielch/ProductUpdateService/**
check.Updatehttp://people.apache.org/%7Earielch/ProductUpdateService/check.Update
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Well, foo, when I do this replacement, it does work as you say! Darn!
OK,
let me re-investigate why the other snippet with my internal host
redirect
isn't working quite right! :(
How are doing this redirect?
Regards,
Dave
I've got the following in my local /etc/hosts
140.211.11.131
update36.services.openoffice.**orghttp://update36.services.openoffice.org
here are versions I've played with in versionrc (I split the lines for
easier reading for you)
++**+++
[Version]
AllLanguages=en-US
buildid=330m20(Build:9567)
ExtensionUpdateURL=
http://updateexte.services.**openoffice.org/**
ExtensionUpdateService/check.**Updatehttp://updateexte.services.openoffice.org/ExtensionUpdateService/check.Update
OOOBaseVersion=3.3
ProductBuildid=9567
ProductMajor=330
ProductMinor=20
ProductSource=OOO330
UpdateID=OpenOffice.org_3_en-**US
#UpdateURL=
http://update36.services.**openoffice.org/**ProductUpdateService/check.*
*Update?pkgfmt=rpmhttp://update36.services.openoffice.org/ProductUpdateService/check.Update?pkgfmt=rpm
UpdateURL=
http://update36.services.**openoffice.org/**ProductUpdateService/check.*
*Updatehttp://update36.services.openoffice.org/ProductUpdateService/check.Update
#UpdateURL=
http://people.apache.org/~**arielch/ProductUpdateService/**
check.Update?pkgfmt=rpmhttp://people.apache.org/%7Earielch/ProductUpdateService/check.Update?pkgfmt=rpm
UpdateUserAgent=PRODUCT (${buildid}; ${_OS}; ${_ARCH};
BundledLanguages=${**AllLanguages})
++**
using Ariel's returns no update. Using the current one with the
redirect
returns the error business. (i mean it connects but I get a different
message, a failed...)
Things of note vis a vis people.apache.org vs www.openoffice.org (where
I
have the current re-route)
If you just bring up:
http://www.openoffice.org/**ProductUpdateService/check.**Updatehttp://www.openoffice.org/ProductUpdateService/check.Update
vs
http://people.apache.org/~**arielch/ProductUpdateService/**check.Updatehttp://people.apache.org/%7Earielch/ProductUpdateService/check.Update
they look different in my browser...one has UTF-8 vs utf-8
so I'm curious about this. I did up a little cgi and ran it on both
people.apache.org and well, ooo-site-staging.apache.org and they both
produce the same environment info. So ???
http://people.apache.org/~**kschenk/cgi-bin/env.cgihttp://people.apache.org/%7Ekschenk/cgi-bin/env.cgi
http://ooo-site.staging.**apache.org/cgi-bin/env.cgihttp://ooo-site.staging.apache.org/cgi-bin/env.cgi
I will change the UTF-8 to utf-8 on www.openoffice.org and see
Re: update service - proposal for temporary solution until AOO 3.4 is released.
On Wed, Mar 21, 2012 at 1:06 PM, Dave Fisher dave2w...@comcast.net wrote:
On Mar 21, 2012, at 9:09 AM, Kay Schenk wrote:
On Wed, Mar 21, 2012 at 1:48 AM, Oliver-Rainer Wittmann
orwittm...@googlemail.com wrote:
Hi,
On 21.03.2012 00:33, Kay Schenk wrote:
On Tue, Mar 20, 2012 at 2:36 PM, Kay Schenkkay.sch...@gmail.com
wrote:
On Tue, Mar 20, 2012 at 10:01 AM, Dave Fisherdave2w...@comcast.net
**
wrote:
On Mar 20, 2012, at 9:45 AM, Kay Schenk wrote:
On Mon, Mar 19, 2012 at 5:31 PM, Ariel Constenla-Haile
arie...@apache.orgwrote:
Hi Kay,
On Mon, Mar 19, 2012 at 03:42:22PM -0700, Kay Schenk wrote:
Well interesting...I did some editing of versionrc and now I get
that
an
update does not exist after pulling off the pkgfmt=rpm requirement.
However, we can not expect users of existing product to go messing
with
their existing setups (i.e. editing files). I don't mind the odd
message
I
was getting before about an rpm package not being found.
I'm just wondering if there's some way to configure the snippet
you
sent
to
just do something a bit more friendly for all possible situations
that
are
currently out there now.
Thoughts? Any experts on how to create a generic null feed?
I tried with my original empty xml file (not a feed) and it works
as
expected with every combination:
UpdateURL=
http://people.apache.org/~**arielch/ProductUpdateService/**
check.Update
http://people.apache.org/%7Earielch/ProductUpdateService/check.Update
UpdateURL=
http://people.apache.org/~**arielch/ProductUpdateService/**
check.Update?pkgfmt=rpm
http://people.apache.org/%7Earielch/ProductUpdateService/check.Update?pkgfmt=rpm
UpdateURL=
http://people.apache.org/~**arielch/ProductUpdateService/**
check.Update?pkgfmt=deb
http://people.apache.org/%7Earielch/ProductUpdateService/check.Update?pkgfmt=deb
UpdateURL=
http://people.apache.org/~**arielch/ProductUpdateService/**
check.Update?pkgfmt=dmg
http://people.apache.org/%7Earielch/ProductUpdateService/check.Update?pkgfmt=dmg
I can't see why it does not work for you.
Please try pointing the UpdateURL to this file
http://people.apache.org/~**arielch/ProductUpdateService/**
check.Update
http://people.apache.org/%7Earielch/ProductUpdateService/check.Update
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Well, foo, when I do this replacement, it does work as you say!
Darn!
OK,
let me re-investigate why the other snippet with my internal host
redirect
isn't working quite right! :(
How are doing this redirect?
Regards,
Dave
I've got the following in my local /etc/hosts
140.211.11.131 update36.services.openoffice.**org
http://update36.services.openoffice.org
here are versions I've played with in versionrc (I split the lines
for
easier reading for you)
++**+++
[Version]
AllLanguages=en-US
buildid=330m20(Build:9567)
ExtensionUpdateURL=
http://updateexte.services.**openoffice.org/**
ExtensionUpdateService/check.**Update
http://updateexte.services.openoffice.org/ExtensionUpdateService/check.Update
OOOBaseVersion=3.3
ProductBuildid=9567
ProductMajor=330
ProductMinor=20
ProductSource=OOO330
UpdateID=OpenOffice.org_3_en-**US
#UpdateURL=
http://update36.services.**
openoffice.org/**ProductUpdateService/check.*
*Update?pkgfmt=rpm
http://update36.services.openoffice.org/ProductUpdateService/check.Update?pkgfmt=rpm
UpdateURL=
http://update36.services.**
openoffice.org/**ProductUpdateService/check.*
*Update
http://update36.services.openoffice.org/ProductUpdateService/check.Update
#UpdateURL=
http://people.apache.org/~**arielch/ProductUpdateService/**
check.Update?pkgfmt=rpm
http://people.apache.org/%7Earielch/ProductUpdateService/check.Update?pkgfmt=rpm
UpdateUserAgent=PRODUCT (${buildid}; ${_OS}; ${_ARCH};
BundledLanguages=${**AllLanguages})
++**
using Ariel's returns no update. Using the current one with the
redirect
returns the error business. (i mean it connects but I get a different
message, a failed...)
Things of note vis a vis people.apache.org vs www.openoffice.org(where
I
have the current re-route)
If you just bring up:
http://www.openoffice.org/**ProductUpdateService/check.**Update
http://www.openoffice.org/ProductUpdateService/check.Update
vs
http://people.apache.org/~**arielch/ProductUpdateService/**check.Update
http://people.apache.org/%7Earielch/ProductUpdateService/check.Update
they look different in my browser...one has UTF-8 vs utf-8
so I'm curious about this. I did up a little cgi and ran it on both
people.apache.org and well, ooo-site-staging.apache.org and they both
produce the same environment info. So ???
Re: update service - proposal for temporary solution until AOO 3.4 is released.
On Mon, Mar 19, 2012 at 5:31 PM, Ariel Constenla-Haile arie...@apache.orgwrote: Hi Kay, On Mon, Mar 19, 2012 at 03:42:22PM -0700, Kay Schenk wrote: Well interesting...I did some editing of versionrc and now I get that an update does not exist after pulling off the pkgfmt=rpm requirement. However, we can not expect users of existing product to go messing with their existing setups (i.e. editing files). I don't mind the odd message I was getting before about an rpm package not being found. I'm just wondering if there's some way to configure the snippet you sent to just do something a bit more friendly for all possible situations that are currently out there now. Thoughts? Any experts on how to create a generic null feed? I tried with my original empty xml file (not a feed) and it works as expected with every combination: UpdateURL= http://people.apache.org/~arielch/ProductUpdateService/check.Update UpdateURL=http://people.apache.org/~arielch/ProductUpdateService/check.Update?pkgfmt=rpm UpdateURL=http://people.apache.org/~arielch/ProductUpdateService/check.Update?pkgfmt=deb UpdateURL=http://people.apache.org/~arielch/ProductUpdateService/check.Update?pkgfmt=dmg I can't see why it does not work for you. Please try pointing the UpdateURL to this file http://people.apache.org/~arielch/ProductUpdateService/check.Update Regards -- Ariel Constenla-Haile La Plata, Argentina Well, foo, when I do this replacement, it does work as you say! Darn! OK, let me re-investigate why the other snippet with my internal host redirect isn't working quite right! :( -- MzK Follow your bliss. -- attributed to Joseph Campbell
Re: update service - proposal for temporary solution until AOO 3.4 is released.
On Mar 20, 2012, at 9:45 AM, Kay Schenk wrote: On Mon, Mar 19, 2012 at 5:31 PM, Ariel Constenla-Haile arie...@apache.orgwrote: Hi Kay, On Mon, Mar 19, 2012 at 03:42:22PM -0700, Kay Schenk wrote: Well interesting...I did some editing of versionrc and now I get that an update does not exist after pulling off the pkgfmt=rpm requirement. However, we can not expect users of existing product to go messing with their existing setups (i.e. editing files). I don't mind the odd message I was getting before about an rpm package not being found. I'm just wondering if there's some way to configure the snippet you sent to just do something a bit more friendly for all possible situations that are currently out there now. Thoughts? Any experts on how to create a generic null feed? I tried with my original empty xml file (not a feed) and it works as expected with every combination: UpdateURL= http://people.apache.org/~arielch/ProductUpdateService/check.Update UpdateURL=http://people.apache.org/~arielch/ProductUpdateService/check.Update?pkgfmt=rpm UpdateURL=http://people.apache.org/~arielch/ProductUpdateService/check.Update?pkgfmt=deb UpdateURL=http://people.apache.org/~arielch/ProductUpdateService/check.Update?pkgfmt=dmg I can't see why it does not work for you. Please try pointing the UpdateURL to this file http://people.apache.org/~arielch/ProductUpdateService/check.Update Regards -- Ariel Constenla-Haile La Plata, Argentina Well, foo, when I do this replacement, it does work as you say! Darn! OK, let me re-investigate why the other snippet with my internal host redirect isn't working quite right! :( How are doing this redirect? Regards, Dave -- MzK Follow your bliss. -- attributed to Joseph Campbell
Re: update service - proposal for temporary solution until AOO 3.4 is released.
On Tue, Mar 20, 2012 at 10:01 AM, Dave Fisher dave2w...@comcast.net wrote:
On Mar 20, 2012, at 9:45 AM, Kay Schenk wrote:
On Mon, Mar 19, 2012 at 5:31 PM, Ariel Constenla-Haile
arie...@apache.orgwrote:
Hi Kay,
On Mon, Mar 19, 2012 at 03:42:22PM -0700, Kay Schenk wrote:
Well interesting...I did some editing of versionrc and now I get that
an
update does not exist after pulling off the pkgfmt=rpm requirement.
However, we can not expect users of existing product to go messing with
their existing setups (i.e. editing files). I don't mind the odd
message
I
was getting before about an rpm package not being found.
I'm just wondering if there's some way to configure the snippet you
sent
to
just do something a bit more friendly for all possible situations that
are
currently out there now.
Thoughts? Any experts on how to create a generic null feed?
I tried with my original empty xml file (not a feed) and it works as
expected with every combination:
UpdateURL=
http://people.apache.org/~arielch/ProductUpdateService/check.Update
UpdateURL=
http://people.apache.org/~arielch/ProductUpdateService/check.Update?pkgfmt=rpm
UpdateURL=
http://people.apache.org/~arielch/ProductUpdateService/check.Update?pkgfmt=deb
UpdateURL=
http://people.apache.org/~arielch/ProductUpdateService/check.Update?pkgfmt=dmg
I can't see why it does not work for you.
Please try pointing the UpdateURL to this file
http://people.apache.org/~arielch/ProductUpdateService/check.Update
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Well, foo, when I do this replacement, it does work as you say! Darn! OK,
let me re-investigate why the other snippet with my internal host
redirect
isn't working quite right! :(
How are doing this redirect?
Regards,
Dave
I've got the following in my local /etc/hosts
140.211.11.131 update36.services.openoffice.org
here are versions I've played with in versionrc (I split the lines for
easier reading for you)
+
[Version]
AllLanguages=en-US
buildid=330m20(Build:9567)
ExtensionUpdateURL=
http://updateexte.services.openoffice.org/ExtensionUpdateService/check.Update
OOOBaseVersion=3.3
ProductBuildid=9567
ProductMajor=330
ProductMinor=20
ProductSource=OOO330
UpdateID=OpenOffice.org_3_en-US
#UpdateURL=
http://update36.services.openoffice.org/ProductUpdateService/check.Update?pkgfmt=rpm
UpdateURL=
http://update36.services.openoffice.org/ProductUpdateService/check.Update
#UpdateURL=
http://people.apache.org/~arielch/ProductUpdateService/check.Update?pkgfmt=rpm
UpdateUserAgent=PRODUCT (${buildid}; ${_OS}; ${_ARCH};
BundledLanguages=${AllLanguages})
++
using Ariel's returns no update. Using the current one with the redirect
returns the error business. (i mean it connects but I get a different
message, a failed...)
Things of note vis a vis people.apache.org vs www.openoffice.org (where I
have the current re-route)
If you just bring up:
http://www.openoffice.org/ProductUpdateService/check.Update
vs
http://people.apache.org/~arielch/ProductUpdateService/check.Update
they look different in my browser...one has UTF-8 vs utf-8
so I'm curious about this. I did up a little cgi and ran it on both
people.apache.org and well, ooo-site-staging.apache.org and they both
produce the same environment info. So ???
http://people.apache.org/~kschenk/cgi-bin/env.cgi
http://ooo-site.staging.apache.org/cgi-bin/env.cgi
I will change the UTF-8 to utf-8 on www.openoffice.org and see what
happens. Also did a diff on them and nothing but the case business.
Meanwhile -- do you know how we get cgi to run on www.openoffice.org? I see
we have a directory for this. I dumped some test scripts in it, but
www.openoffice.org/cgi-bin/h.cgi (Hello World) preoduces nothing. :(
If not, I will get in touch with INFRA.
--
MzK
Follow your bliss.
-- attributed to Joseph Campbell
--
MzK
Follow your bliss.
-- attributed to Joseph Campbell
Re: update service - proposal for temporary solution until AOO 3.4 is released.
Hi, On 18.03.2012 18:10, Kay Schenk wrote: On Thu, Mar 15, 2012 at 5:03 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, On 15.03.2012 12:47, Oliver-Rainer Wittmann wrote: Hi, I have continued the work started by Regina, Ariel and Kay regarding the update service. I have documented my findings at [1]. I think we have everything together to bring a corresponding web service back to life. I think we have at least two options for such a web service. If we want to create a 'real' web service which on demand creates an appropriate response the HTTP GET request contains all needed information in its header fields User-Agent and Accept-Language to implement such a web service. The User-Agent field contains the operating system, the machine architecture and the bundled languages of the installed office. If a corresponding installation package of newer version is available a corresponding response can be generated. Another solution could be to provide a static XML document, based on an atom feed, which contains as much entries as installation packages for the latest version are available. For each installation package which defines itself by the operating system, the machine architecture and the bundled languages an entry is needed. Such entries need to be duplicated for every existing office installation with differentUpdateID in its version.ini. Any thoughts, comments, corrections, ...? BTW, the update service of a certain installed office can be tested locally. No HTTP GET request is involved in this case, but you can test with certain XML documents provided as responses. You can change the value ofUpdateURL in file version.ini of your office installation to a local file URL - e.g. under Windows to something like file:///C:/check.update.xml [1] http://wiki.services.**openoffice.org/wiki/Update_** Notification_Protocol#A_**glance_on_the_code_for_the_** Apache_OpenOffice_3.4_releasehttp://wiki.services.openoffice.org/wiki/Update_Notification_Protocol#A_glance_on_the_code_for_the_Apache_OpenOffice_3.4_release TheUpdateURL in the installed OOo 3.3 instances is http://update36.services.**openoffice.org/**ProductUpdateService/check.** Updatehttp://update36.services.openoffice.org/ProductUpdateService/check.Update . This is no longer available. This also annoys our users I think. If we can redirect this URL and the redirection would provide the following XML document the corresponding update service in these offices will reply your office is up to date The XML document which needs to be provided only has to contain this XML snippet: ?xml version=1.0 encoding=UTF-8? inst:description xmlns:inst=http://**installation.openoffice.org/** descriptionhttp://installation.openoffice.org/description /inst:description Can someone implement the redirect? May be http://www.openoffice.org/**ProductUpdateService/check.**Updatehttp://www.openoffice.org/ProductUpdateService/check.Updatecan be used as the redirect. Here, I think it was Kay, already an XML document exists which only needs to be updated. Note: I have also an OOo 3.1 installed. Here theUpdateURL is http://update32.services.**openoffice.org/**ProductUpdateService/check.** Updatehttp://update32.services.openoffice.org/ProductUpdateService/check.Update . May be we should redirect all URL matching http://update3[0..6].services.* *openoffice.org/**ProductUpdateService/check.**Updatehttp://services.openoffice.org/ProductUpdateService/check.Update Oliver-- Hi -- I missed this post until just now. I can put this code snippet in in http://www.openoffice.org/ProductUpdateService/check.Update as you suggest. ...and send a note to INFRA regarding the DNS changes However, I'm a bit concerned with telling users (and perhaps folks using a very old version) that their version is up to date when it isn't. Is this all we can do about this right now? May be we should revise my above proposal as a temporary solution until AOO 3.4 is ready: - redirect URL http://update36.services... to the new URL -- OOo 3.3.0 update service should answer with a up to date - redirect URLs http://update3[0..5].services... to another URL which provides an XML snippet containing the download link to the OOo 3.3.0 download website. -- OOo 3.0.0 ... OOo 3.2.1 update service should answer with a update available, please go to ... A con of this solution would be that even, if the download link does not contain any package for the specific installed OOo 3.0.0 ... OOo 3.2.1 Any further thoughts? Best regards, Oliver.
Re: update service - proposal for temporary solution until AOO 3.4 is released.
Hi On 18.03.2012 22:14, Kay Schenk wrote: On Sun, Mar 18, 2012 at 10:10 AM, Kay Schenkkay.sch...@gmail.com wrote: On Thu, Mar 15, 2012 at 5:03 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, On 15.03.2012 12:47, Oliver-Rainer Wittmann wrote: Hi, I have continued the work started by Regina, Ariel and Kay regarding the update service. I have documented my findings at [1]. I think we have everything together to bring a corresponding web service back to life. I think we have at least two options for such a web service. If we want to create a 'real' web service which on demand creates an appropriate response the HTTP GET request contains all needed information in its header fields User-Agent and Accept-Language to implement such a web service. The User-Agent field contains the operating system, the machine architecture and the bundled languages of the installed office. If a corresponding installation package of newer version is available a corresponding response can be generated. Another solution could be to provide a static XML document, based on an atom feed, which contains as much entries as installation packages for the latest version are available. For each installation package which defines itself by the operating system, the machine architecture and the bundled languages an entry is needed. Such entries need to be duplicated for every existing office installation with differentUpdateID in its version.ini. Any thoughts, comments, corrections, ...? BTW, the update service of a certain installed office can be tested locally. No HTTP GET request is involved in this case, but you can test with certain XML documents provided as responses. You can change the value ofUpdateURL in file version.ini of your office installation to a local file URL - e.g. under Windows to something like file:///C:/check.update.xml [1] http://wiki.services.**openoffice.org/wiki/Update_** Notification_Protocol#A_**glance_on_the_code_for_the_** Apache_OpenOffice_3.4_releasehttp://wiki.services.openoffice.org/wiki/Update_Notification_Protocol#A_glance_on_the_code_for_the_Apache_OpenOffice_3.4_release TheUpdateURL in the installed OOo 3.3 instances is http://update36.services.**openoffice.org/**ProductUpdateService/check.** Updatehttp://update36.services.openoffice.org/ProductUpdateService/check.Update . This is no longer available. This also annoys our users I think. If we can redirect this URL and the redirection would provide the following XML document the corresponding update service in these offices will reply your office is up to date The XML document which needs to be provided only has to contain this XML snippet: ?xml version=1.0 encoding=UTF-8? inst:description xmlns:inst=http://**installation.openoffice.org/** descriptionhttp://installation.openoffice.org/description /inst:description Can someone implement the redirect? Oliver -- Hi. I put your snippet out there just a bit ago...and this is what I currently get as a message from Check for Updates in OOo 3.3... ++ Staus: Checking for an update failed. Description: http://update36.services.openoffice.org/ProductUpdateService/check.Update?pkgfmt=rpmdoes not exist. + so not exactly what you said but at least OOo doesn't spend time trying to connect to something that doesn't exist ...I have update36.services.openoffice.org routed to the web server with your new snippet in place. Hm... I tested only on Windows with OOo 3.3.0 and OOo 3.1.0 by replace the UpdateID in the file version.ini by a URL to the local file system. Do you have the possibility to try this also with your installation? May be I have overlooked something in the code. Best regards, Oliver.
Re: update service - proposal for temporary solution until AOO 3.4 is released.
On Mon, Mar 19, 2012 at 5:00 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi On 18.03.2012 22:14, Kay Schenk wrote: On Sun, Mar 18, 2012 at 10:10 AM, Kay Schenkkay.sch...@gmail.com wrote: On Thu, Mar 15, 2012 at 5:03 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, On 15.03.2012 12:47, Oliver-Rainer Wittmann wrote: Hi, I have continued the work started by Regina, Ariel and Kay regarding the update service. I have documented my findings at [1]. I think we have everything together to bring a corresponding web service back to life. I think we have at least two options for such a web service. If we want to create a 'real' web service which on demand creates an appropriate response the HTTP GET request contains all needed information in its header fields User-Agent and Accept-Language to implement such a web service. The User-Agent field contains the operating system, the machine architecture and the bundled languages of the installed office. If a corresponding installation package of newer version is available a corresponding response can be generated. Another solution could be to provide a static XML document, based on an atom feed, which contains as much entries as installation packages for the latest version are available. For each installation package which defines itself by the operating system, the machine architecture and the bundled languages an entry is needed. Such entries need to be duplicated for every existing office installation with differentUpdateID in its version.ini. Any thoughts, comments, corrections, ...? BTW, the update service of a certain installed office can be tested locally. No HTTP GET request is involved in this case, but you can test with certain XML documents provided as responses. You can change the value ofUpdateURL in file version.ini of your office installation to a local file URL - e.g. under Windows to something like file:///C:/check.update.xml [1] http://wiki.services.**openoff**ice.org/wiki/Update_**http://openoffice.org/wiki/Update_** Notification_Protocol#A_glance_on_the_code_for_the_** Apache_OpenOffice_3.4_release**http://wiki.services.** openoffice.org/wiki/Update_**Notification_Protocol#A_** glance_on_the_code_for_the_**Apache_OpenOffice_3.4_releasehttp://wiki.services.openoffice.org/wiki/Update_Notification_Protocol#A_glance_on_the_code_for_the_Apache_OpenOffice_3.4_release TheUpdateURL in the installed OOo 3.3 instances is http://update36.services.**ope**noffice.org/ ProductUpdateService/check.**http://openoffice.org/**ProductUpdateService/check.** Updatehttp://update36.**services.openoffice.org/** ProductUpdateService/check.**Updatehttp://update36.services.openoffice.org/ProductUpdateService/check.Update . This is no longer available. This also annoys our users I think. If we can redirect this URL and the redirection would provide the following XML document the corresponding update service in these offices will reply your office is up to date The XML document which needs to be provided only has to contain this XML snippet: ?xml version=1.0 encoding=UTF-8? inst:description xmlns:inst=http://**installat**ion.openoffice.org/**http://installation.openoffice.org/** descriptionhttp://**installation.openoffice.org/**descriptionhttp://installation.openoffice.org/description /inst:description Can someone implement the redirect? Oliver -- Hi. I put your snippet out there just a bit ago...and this is what I currently get as a message from Check for Updates in OOo 3.3... ++ Staus: Checking for an update failed. Description: http://update36.services.**openoffice.org/**ProductUpdateService/check.** Update?pkgfmt=rpmdoeshttp://update36.services.openoffice.org/ProductUpdateService/check.Update?pkgfmt=rpmdoes not exist. + so not exactly what you said but at least OOo doesn't spend time trying to connect to something that doesn't exist ...I have update36.services.openoffice.**orghttp://update36.services.openoffice.orgrouted to the web server with your new snippet in place. Hm... I tested only on Windows with OOo 3.3.0 and OOo 3.1.0 by replace the UpdateID in the file version.ini by a URL to the local file system. Do you have the possibility to try this also with your installation? May be I have overlooked something in the code. Best regards, Oliver. Oliver-- I am not following here. I have an old binary version of 3.3 installed as a normal user would. I do not have a version.ini file -- this is part of the source not the delivered binary. Users would not be expecting to change files associated with the product to deal with this. In other words, we need/should come up with a reply that will work with existing installs that will not require any other changes. Am I missing something? --
Re: update service - proposal for temporary solution until AOO 3.4 is released.
Hi Kay, On 19.03.2012 17:04, Kay Schenk wrote: On Mon, Mar 19, 2012 at 5:00 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi On 18.03.2012 22:14, Kay Schenk wrote: On Sun, Mar 18, 2012 at 10:10 AM, Kay Schenkkay.sch...@gmail.com wrote: On Thu, Mar 15, 2012 at 5:03 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, On 15.03.2012 12:47, Oliver-Rainer Wittmann wrote: Hi, I have continued the work started by Regina, Ariel and Kay regarding the update service. I have documented my findings at [1]. I think we have everything together to bring a corresponding web service back to life. I think we have at least two options for such a web service. If we want to create a 'real' web service which on demand creates an appropriate response the HTTP GET request contains all needed information in its header fields User-Agent and Accept-Language to implement such a web service. The User-Agent field contains the operating system, the machine architecture and the bundled languages of the installed office. If a corresponding installation package of newer version is available a corresponding response can be generated. Another solution could be to provide a static XML document, based on an atom feed, which contains as much entries as installation packages for the latest version are available. For each installation package which defines itself by the operating system, the machine architecture and the bundled languages an entry is needed. Such entries need to be duplicated for every existing office installation with differentUpdateID in its version.ini. Any thoughts, comments, corrections, ...? BTW, the update service of a certain installed office can be tested locally. No HTTP GET request is involved in this case, but you can test with certain XML documents provided as responses. You can change the value ofUpdateURL in file version.ini of your office installation to a local file URL - e.g. under Windows to something like file:///C:/check.update.xml [1] http://wiki.services.**openoff**ice.org/wiki/Update_**http://openoffice.org/wiki/Update_** Notification_Protocol#A_glance_on_the_code_for_the_** Apache_OpenOffice_3.4_release**http://wiki.services.** openoffice.org/wiki/Update_**Notification_Protocol#A_** glance_on_the_code_for_the_**Apache_OpenOffice_3.4_releasehttp://wiki.services.openoffice.org/wiki/Update_Notification_Protocol#A_glance_on_the_code_for_the_Apache_OpenOffice_3.4_release TheUpdateURL in the installed OOo 3.3 instances is http://update36.services.**ope**noffice.org/ ProductUpdateService/check.**http://openoffice.org/**ProductUpdateService/check.** Updatehttp://update36.**services.openoffice.org/** ProductUpdateService/check.**Updatehttp://update36.services.openoffice.org/ProductUpdateService/check.Update . This is no longer available. This also annoys our users I think. If we can redirect this URL and the redirection would provide the following XML document the corresponding update service in these offices will reply your office is up to date The XML document which needs to be provided only has to contain this XML snippet: ?xml version=1.0 encoding=UTF-8? inst:description xmlns:inst=http://**installat**ion.openoffice.org/**http://installation.openoffice.org/** descriptionhttp://**installation.openoffice.org/**descriptionhttp://installation.openoffice.org/description /inst:description Can someone implement the redirect? Oliver -- Hi. I put your snippet out there just a bit ago...and this is what I currently get as a message from Check for Updates in OOo 3.3... ++ Staus: Checking for an update failed. Description: http://update36.services.**openoffice.org/**ProductUpdateService/check.** Update?pkgfmt=rpmdoeshttp://update36.services.openoffice.org/ProductUpdateService/check.Update?pkgfmt=rpmdoes not exist. + so not exactly what you said but at least OOo doesn't spend time trying to connect to something that doesn't exist ...I have update36.services.openoffice.**orghttp://update36.services.openoffice.orgrouted to the web server with your new snippet in place. Hm... I tested only on Windows with OOo 3.3.0 and OOo 3.1.0 by replace the UpdateID in the fileversion.ini by a URL to the local file system. Do you have the possibility to try this also with your installation? May be I have overlooked something in the code. Best regards, Oliver. Oliver-- I am not following here. I have an old binary version of 3.3 installed as a normal user would. I do not have a version.ini file -- this is part of the source not the delivered binary. Users would not be expecting to change files associated with the product to deal with this. In other words, we need/should come up with a reply that will work with existing installs that will not require any other changes. Am I missing something? it is only for testing XML snippets which would be provided as the response
Re: update service - proposal for temporary solution until AOO 3.4 is released.
On Mon, Mar 19, 2012 at 1:40 PM, Ariel Constenla-Haile arie...@apache.orgwrote: Hi *, On Mon, Mar 19, 2012 at 05:10:18PM +0100, Oliver-Rainer Wittmann wrote: Oliver-- I am not following here. I have an old binary version of 3.3 installed as a normal user would. I do not have a version.ini file -- this is part of the source not the delivered binary. Users would not be expecting to change files associated with the product to deal with this. In other words, we need/should come up with a reply that will work with existing installs that will not require any other changes. Am I missing something? it is only for testing XML snippets which would be provided as the response to the HTTP GET request. You should have a version.* file in your installation. Under Windows it is named version.ini. Under Linux and MacOS X it is named version.rc. [ It looks like that I am too much focused on Windows ;-) ] IIRC Kay is a Linux user, on Linux you'll find the file on /opt/openoffice.org3/program/versionrc You can make it point to a regular file using file:// instead of http:// Regards -- Ariel Constenla-Haile La Plata, Argentina Well interesting...I did some editing of versionrc and now I get that an update does not exist after pulling off the pkgfmt=rpm requirement. However, we can not expect users of existing product to go messing with their existing setups (i.e. editing files). I don't mind the odd message I was getting before about an rpm package not being found. I'm just wondering if there's some way to configure the snippet you sent to just do something a bit more friendly for all possible situations that are currently out there now. Thoughts? Any experts on how to create a generic null feed? -- MzK Follow your bliss. -- attributed to Joseph Campbell
Re: update service - proposal for temporary solution until AOO 3.4 is released.
Hi Kay, On Mon, Mar 19, 2012 at 03:42:22PM -0700, Kay Schenk wrote: Well interesting...I did some editing of versionrc and now I get that an update does not exist after pulling off the pkgfmt=rpm requirement. However, we can not expect users of existing product to go messing with their existing setups (i.e. editing files). I don't mind the odd message I was getting before about an rpm package not being found. I'm just wondering if there's some way to configure the snippet you sent to just do something a bit more friendly for all possible situations that are currently out there now. Thoughts? Any experts on how to create a generic null feed? I tried with my original empty xml file (not a feed) and it works as expected with every combination: UpdateURL=http://people.apache.org/~arielch/ProductUpdateService/check.Update UpdateURL=http://people.apache.org/~arielch/ProductUpdateService/check.Update?pkgfmt=rpm UpdateURL=http://people.apache.org/~arielch/ProductUpdateService/check.Update?pkgfmt=deb UpdateURL=http://people.apache.org/~arielch/ProductUpdateService/check.Update?pkgfmt=dmg I can't see why it does not work for you. Please try pointing the UpdateURL to this file http://people.apache.org/~arielch/ProductUpdateService/check.Update Regards -- Ariel Constenla-Haile La Plata, Argentina pgpiyanm5lZjv.pgp Description: PGP signature
Re: update service - proposal for temporary solution until AOO 3.4 is released.
On Thu, Mar 15, 2012 at 5:03 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, On 15.03.2012 12:47, Oliver-Rainer Wittmann wrote: Hi, I have continued the work started by Regina, Ariel and Kay regarding the update service. I have documented my findings at [1]. I think we have everything together to bring a corresponding web service back to life. I think we have at least two options for such a web service. If we want to create a 'real' web service which on demand creates an appropriate response the HTTP GET request contains all needed information in its header fields User-Agent and Accept-Language to implement such a web service. The User-Agent field contains the operating system, the machine architecture and the bundled languages of the installed office. If a corresponding installation package of newer version is available a corresponding response can be generated. Another solution could be to provide a static XML document, based on an atom feed, which contains as much entries as installation packages for the latest version are available. For each installation package which defines itself by the operating system, the machine architecture and the bundled languages an entry is needed. Such entries need to be duplicated for every existing office installation with different UpdateID in its version.ini. Any thoughts, comments, corrections, ...? BTW, the update service of a certain installed office can be tested locally. No HTTP GET request is involved in this case, but you can test with certain XML documents provided as responses. You can change the value of UpdateURL in file version.ini of your office installation to a local file URL - e.g. under Windows to something like file:///C:/check.update.xml [1] http://wiki.services.**openoffice.org/wiki/Update_** Notification_Protocol#A_**glance_on_the_code_for_the_** Apache_OpenOffice_3.4_releasehttp://wiki.services.openoffice.org/wiki/Update_Notification_Protocol#A_glance_on_the_code_for_the_Apache_OpenOffice_3.4_release The UpdateURL in the installed OOo 3.3 instances is http://update36.services.**openoffice.org/**ProductUpdateService/check.** Updatehttp://update36.services.openoffice.org/ProductUpdateService/check.Update . This is no longer available. This also annoys our users I think. If we can redirect this URL and the redirection would provide the following XML document the corresponding update service in these offices will reply your office is up to date The XML document which needs to be provided only has to contain this XML snippet: ?xml version=1.0 encoding=UTF-8? inst:description xmlns:inst=http://**installation.openoffice.org/** description http://installation.openoffice.org/description /inst:description Can someone implement the redirect? May be http://www.openoffice.org/**ProductUpdateService/check.**Updatehttp://www.openoffice.org/ProductUpdateService/check.Updatecan be used as the redirect. Here, I think it was Kay, already an XML document exists which only needs to be updated. Note: I have also an OOo 3.1 installed. Here the UpdateURL is http://update32.services.**openoffice.org/**ProductUpdateService/check.** Updatehttp://update32.services.openoffice.org/ProductUpdateService/check.Update . May be we should redirect all URL matching http://update3[0..6].services.* *openoffice.org/**ProductUpdateService/check.**Updatehttp://services.openoffice.org/ProductUpdateService/check.Update Oliver-- Hi -- I missed this post until just now. I can put this code snippet in in http://www.openoffice.org/ProductUpdateService/check.Update as you suggest. ...and send a note to INFRA regarding the DNS changes However, I'm a bit concerned with telling users (and perhaps folks using a very old version) that their version is up to date when it isn't. Is this all we can do about this right now? Best regards, Oliver. -- MzK Follow your bliss. -- attributed to Joseph Campbell
Re: update service - proposal for temporary solution until AOO 3.4 is released.
On Sun, Mar 18, 2012 at 10:10 AM, Kay Schenk kay.sch...@gmail.com wrote: On Thu, Mar 15, 2012 at 5:03 AM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, On 15.03.2012 12:47, Oliver-Rainer Wittmann wrote: Hi, I have continued the work started by Regina, Ariel and Kay regarding the update service. I have documented my findings at [1]. I think we have everything together to bring a corresponding web service back to life. I think we have at least two options for such a web service. If we want to create a 'real' web service which on demand creates an appropriate response the HTTP GET request contains all needed information in its header fields User-Agent and Accept-Language to implement such a web service. The User-Agent field contains the operating system, the machine architecture and the bundled languages of the installed office. If a corresponding installation package of newer version is available a corresponding response can be generated. Another solution could be to provide a static XML document, based on an atom feed, which contains as much entries as installation packages for the latest version are available. For each installation package which defines itself by the operating system, the machine architecture and the bundled languages an entry is needed. Such entries need to be duplicated for every existing office installation with different UpdateID in its version.ini. Any thoughts, comments, corrections, ...? BTW, the update service of a certain installed office can be tested locally. No HTTP GET request is involved in this case, but you can test with certain XML documents provided as responses. You can change the value of UpdateURL in file version.ini of your office installation to a local file URL - e.g. under Windows to something like file:///C:/check.update.xml [1] http://wiki.services.**openoffice.org/wiki/Update_** Notification_Protocol#A_**glance_on_the_code_for_the_** Apache_OpenOffice_3.4_releasehttp://wiki.services.openoffice.org/wiki/Update_Notification_Protocol#A_glance_on_the_code_for_the_Apache_OpenOffice_3.4_release The UpdateURL in the installed OOo 3.3 instances is http://update36.services.**openoffice.org/**ProductUpdateService/check.** Updatehttp://update36.services.openoffice.org/ProductUpdateService/check.Update . This is no longer available. This also annoys our users I think. If we can redirect this URL and the redirection would provide the following XML document the corresponding update service in these offices will reply your office is up to date The XML document which needs to be provided only has to contain this XML snippet: ?xml version=1.0 encoding=UTF-8? inst:description xmlns:inst=http://**installation.openoffice.org/** description http://installation.openoffice.org/description /inst:description Can someone implement the redirect? Oliver -- Hi. I put your snippet out there just a bit ago...and this is what I currently get as a message from Check for Updates in OOo 3.3... ++ Staus: Checking for an update failed. Description: http://update36.services.openoffice.org/ProductUpdateService/check.Update?pkgfmt=rpmdoes not exist. + so not exactly what you said but at least OOo doesn't spend time trying to connect to something that doesn't exist ...I have update36.services.openoffice.org routed to the web server with your new snippet in place. May be http://www.openoffice.org/**ProductUpdateService/check.**Updatehttp://www.openoffice.org/ProductUpdateService/check.Updatecan be used as the redirect. Here, I think it was Kay, already an XML document exists which only needs to be updated. Note: I have also an OOo 3.1 installed. Here the UpdateURL is http://update32.services.**openoffice.org/**ProductUpdateService/check.** Updatehttp://update32.services.openoffice.org/ProductUpdateService/check.Update . May be we should redirect all URL matching http://update3[0..6].services. **openoffice.org/**ProductUpdateService/check.**Updatehttp://services.openoffice.org/ProductUpdateService/check.Update Oliver-- Hi -- I missed this post until just now. I can put this code snippet in in http://www.openoffice.org/ProductUpdateService/check.Update as you suggest. ...and send a note to INFRA regarding the DNS changes However, I'm a bit concerned with telling users (and perhaps folks using a very old version) that their version is up to date when it isn't. Is this all we can do about this right now? Best regards, Oliver. -- MzK Follow your bliss. -- attributed to Joseph Campbell -- MzK Follow your bliss. -- attributed to Joseph Campbell
Re: update service - proposal for temporary solution until AOO 3.4 is released.
Hi, On 15.03.2012 12:47, Oliver-Rainer Wittmann wrote: Hi, I have continued the work started by Regina, Ariel and Kay regarding the update service. I have documented my findings at [1]. I think we have everything together to bring a corresponding web service back to life. I think we have at least two options for such a web service. If we want to create a 'real' web service which on demand creates an appropriate response the HTTP GET request contains all needed information in its header fields User-Agent and Accept-Language to implement such a web service. The User-Agent field contains the operating system, the machine architecture and the bundled languages of the installed office. If a corresponding installation package of newer version is available a corresponding response can be generated. Another solution could be to provide a static XML document, based on an atom feed, which contains as much entries as installation packages for the latest version are available. For each installation package which defines itself by the operating system, the machine architecture and the bundled languages an entry is needed. Such entries need to be duplicated for every existing office installation with different UpdateID in its version.ini. Any thoughts, comments, corrections, ...? BTW, the update service of a certain installed office can be tested locally. No HTTP GET request is involved in this case, but you can test with certain XML documents provided as responses. You can change the value of UpdateURL in file version.ini of your office installation to a local file URL - e.g. under Windows to something like file:///C:/check.update.xml [1] http://wiki.services.openoffice.org/wiki/Update_Notification_Protocol#A_glance_on_the_code_for_the_Apache_OpenOffice_3.4_release The UpdateURL in the installed OOo 3.3 instances is http://update36.services.openoffice.org/ProductUpdateService/check.Update. This is no longer available. This also annoys our users I think. If we can redirect this URL and the redirection would provide the following XML document the corresponding update service in these offices will reply your office is up to date The XML document which needs to be provided only has to contain this XML snippet: ?xml version=1.0 encoding=UTF-8? inst:description xmlns:inst=http://installation.openoffice.org/description; /inst:description Can someone implement the redirect? May be http://www.openoffice.org/ProductUpdateService/check.Update can be used as the redirect. Here, I think it was Kay, already an XML document exists which only needs to be updated. Note: I have also an OOo 3.1 installed. Here the UpdateURL is http://update32.services.openoffice.org/ProductUpdateService/check.Update. May be we should redirect all URL matching http://update3[0..6].services.openoffice.org/ProductUpdateService/check.Update Best regards, Oliver.
