You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Oliver-Rainer Wittmann <or...@googlemail.com> on 2012/03/15 12:47:41 UTC
update service - further information for such a service
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
Re: update service - proposal for temporary solution until AOO 3.4
is released.
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 18.03.2012 18:10, Kay Schenk wrote:
> On Thu, Mar 15, 2012 at 5:03 AM, Oliver-Rainer Wittmann<
> orwittmann@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_release<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<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<http://installation.openoffice.org/description>">
>> </inst:description>
>>
>> Can someone implement the redirect?
>> May be http://www.openoffice.org/**ProductUpdateService/check.**Update<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<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<http://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.
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
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.Update<http://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.
Posted by Kay Schenk <ka...@gmail.com>.
On Wed, Mar 21, 2012 at 1:06 PM, Dave Fisher <da...@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 <
> > orwittmann@googlemail.com> wrote:
> >
> >> Hi,
> >>
> >>
> >> On 21.03.2012 00:33, Kay Schenk wrote:
> >>
> >>> On Tue, Mar 20, 2012 at 2:36 PM, Kay Schenk<ka...@gmail.com>
> wrote:
> >>>
> >>>
> >>>>
> >>>> On Tue, Mar 20, 2012 at 10:01 AM, Dave Fisher<dave2wave@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
> >>>>>> <ar...@apache.org>wrote:
> >>>>>>
> >>>>>>
> >>>>>>> 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 ???
> >>>>
> >>>> http://people.apache.org/~**kschenk/cgi-bin/env.cgi<
> http://people.apache.org/%7Ekschenk/cgi-bin/env.cgi>
> >>>> http://ooo-site.staging.**apache.org/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<
> http://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.**
> >>> Update <http://www.openoffice.org/ProductUpdateService/check.Update><
> >>> http://people.apache.**org/%7Earielch/**ProductUpdateService/check.**
> >>> Update?pkgfmt=rpm<
> http://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.
> >>
> >
> > yes...I know! :(
> >
> >
> >>
> >> 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<
> http://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<
> http://140.211.11.131/ProductUpdateService/check.Update>using FireFox
> return "404 Not Found".
> >>
> >
> > mine also...
> >
> >
> >> - 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<
> http://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
> >>
> >
> > This is what I got when I browsed to
> > update36.services.openoffice.org/ProductUpdateService/check.Update with
> my
> > redirection in place...
> >
> > * URL redirected to:
> >
> http://openoffice.org/projects/update36/ProductUpdateService/check.Update
>
> The redirect should goto
> http://openoffice.org/ProductUpdateService/check.Update
>
> Ask Infra to change.
>
> Or, add projects/update36 to ooo-site and move/copy the
> ProductUpdateServices/check.Update to that location.
>
>
yes...I'm just about to do this one above and do some tests...
I will open up an "official" [DISCUSSION] on this tomorrow...
>
> >
> > ???? which yielded a "404 not found"
> >
> > OK, I will continue investigating.
> >
> > - reverting the change to my ...\etc\hosts and performing a ping to
> >> update36.services.openoffice.**org<
> http://update36.services.openoffice.org>outputs the following:
> >> <output>
> >> $ ping update36.services.openoffice.**org<
> http://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.
> >>
> >
> > right, this server is dead
> >
> >
> >>
> >> Ping statistics for 192.18.197.109:
> >> Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
> >> </output>
> >>
> >>
> >> Best regards, Oliver.
> >>
> >
> >
> >
> > --
> >
> ----------------------------------------------------------------------------------------
> > MzK
> >
> > "Follow your bliss."
> > -- attributed to Joseph Campbell
>
>
--
----------------------------------------------------------------------------------------
MzK
"Women and cats will do as they please,
and men and dogs should relax and get used to the idea."
--
Robert Heinlein
Re: update service - proposal for temporary solution until AOO 3.4 is released.
Posted by Dave Fisher <da...@comcast.net>.
On Mar 21, 2012, at 9:09 AM, Kay Schenk wrote:
> On Wed, Mar 21, 2012 at 1:48 AM, Oliver-Rainer Wittmann <
> orwittmann@googlemail.com> wrote:
>
>> Hi,
>>
>>
>> On 21.03.2012 00:33, Kay Schenk wrote:
>>
>>> On Tue, Mar 20, 2012 at 2:36 PM, Kay Schenk<ka...@gmail.com> wrote:
>>>
>>>
>>>>
>>>> On Tue, Mar 20, 2012 at 10:01 AM, Dave Fisher<da...@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
>>>>>> <ar...@apache.org>wrote:
>>>>>>
>>>>>>
>>>>>>> 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 ???
>>>>
>>>> http://people.apache.org/~**kschenk/cgi-bin/env.cgi<http://people.apache.org/%7Ekschenk/cgi-bin/env.cgi>
>>>> http://ooo-site.staging.**apache.org/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<http://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.**
>>> Update <http://www.openoffice.org/ProductUpdateService/check.Update><
>>> http://people.apache.**org/%7Earielch/**ProductUpdateService/check.**
>>> Update?pkgfmt=rpm<http://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.
>>
>
> yes...I know! :(
>
>
>>
>> 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<http://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<http://140.211.11.131/ProductUpdateService/check.Update>using FireFox return "404 Not Found".
>>
>
> mine also...
>
>
>> - 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<http://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
>>
>
> This is what I got when I browsed to
> update36.services.openoffice.org/ProductUpdateService/check.Update with my
> redirection in place...
>
> * URL redirected to:
> http://openoffice.org/projects/update36/ProductUpdateService/check.Update
The redirect should goto http://openoffice.org/ProductUpdateService/check.Update
Ask Infra to change.
Or, add projects/update36 to ooo-site and move/copy the ProductUpdateServices/check.Update to that location.
>
> ???? which yielded a "404 not found"
>
> OK, I will continue investigating.
>
> - reverting the change to my ...\etc\hosts and performing a ping to
>> update36.services.openoffice.**org<http://update36.services.openoffice.org>outputs the following:
>> <output>
>> $ ping update36.services.openoffice.**org<http://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.
>>
>
> right, this server is dead
>
>
>>
>> Ping statistics for 192.18.197.109:
>> Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
>> </output>
>>
>>
>> Best regards, Oliver.
>>
>
>
>
> --
> ----------------------------------------------------------------------------------------
> MzK
>
> "Follow your bliss."
> -- attributed to Joseph Campbell
Re: update service - proposal for temporary solution until AOO 3.4 is released.
Posted by Kay Schenk <ka...@gmail.com>.
On Wed, Mar 21, 2012 at 1:48 AM, Oliver-Rainer Wittmann <
orwittmann@googlemail.com> wrote:
> Hi,
>
>
> On 21.03.2012 00:33, Kay Schenk wrote:
>
>> On Tue, Mar 20, 2012 at 2:36 PM, Kay Schenk<ka...@gmail.com> wrote:
>>
>>
>>>
>>> On Tue, Mar 20, 2012 at 10:01 AM, Dave Fisher<da...@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
>>>>> <ar...@apache.org>wrote:
>>>>>
>>>>>
>>>>>> 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 ???
>>>
>>> http://people.apache.org/~**kschenk/cgi-bin/env.cgi<http://people.apache.org/%7Ekschenk/cgi-bin/env.cgi>
>>> http://ooo-site.staging.**apache.org/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<http://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.**
>> Update <http://www.openoffice.org/ProductUpdateService/check.Update><
>> http://people.apache.**org/%7Earielch/**ProductUpdateService/check.**
>> Update?pkgfmt=rpm<http://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.
>
yes...I know! :(
>
> 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<http://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<http://140.211.11.131/ProductUpdateService/check.Update>using FireFox return "404 Not Found".
>
mine also...
> - 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<http://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
>
This is what I got when I browsed to
update36.services.openoffice.org/ProductUpdateService/check.Update with my
redirection in place...
* URL redirected to:
http://openoffice.org/projects/update36/ProductUpdateService/check.Update
???? which yielded a "404 not found"
OK, I will continue investigating.
- reverting the change to my ...\etc\hosts and performing a ping to
> update36.services.openoffice.**org<http://update36.services.openoffice.org>outputs the following:
> <output>
> $ ping update36.services.openoffice.**org<http://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.
>
right, this server is dead
>
> Ping statistics for 192.18.197.109:
> Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
> </output>
>
>
> Best regards, Oliver.
>
--
----------------------------------------------------------------------------------------
MzK
"Follow your bliss."
-- attributed to Joseph Campbell
Re: update service - proposal for temporary solution until AOO 3.4
is released.
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 21.03.2012 00:33, Kay Schenk wrote:
> On Tue, Mar 20, 2012 at 2:36 PM, Kay Schenk<ka...@gmail.com> wrote:
>
>>
>>
>> On Tue, Mar 20, 2012 at 10:01 AM, Dave Fisher<da...@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
>>>> <ar...@apache.org>wrote:
>>>>
>>>>>
>>>>> 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.Update<http://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>
Best regards, Oliver.
Re: update service - proposal for temporary solution until AOO 3.4 is released.
Posted by Kay Schenk <ka...@gmail.com>.
On Tue, Mar 20, 2012 at 2:36 PM, Kay Schenk <ka...@gmail.com> wrote:
>
>
> On Tue, Mar 20, 2012 at 10:01 AM, Dave Fisher <da...@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
>> > <ar...@apache.org>wrote:
>> >
>> >>
>> >> 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.Update<http://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 (???)
>
>
>> >
>> >
>> >
>> > --
>> >
>> ----------------------------------------------------------------------------------------
>> > MzK
>> >
>> > "Follow your bliss."
>> > -- attributed to Joseph Campbell
>>
>>
>
>
> --
>
> ----------------------------------------------------------------------------------------
> 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.
Posted by Kay Schenk <ka...@gmail.com>.
On Tue, Mar 20, 2012 at 10:01 AM, Dave Fisher <da...@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
> > <ar...@apache.org>wrote:
> >
> >>
> >> 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.
Posted by Dave Fisher <da...@comcast.net>.
On Mar 20, 2012, at 9:45 AM, Kay Schenk wrote:
> On Mon, Mar 19, 2012 at 5:31 PM, Ariel Constenla-Haile
> <ar...@apache.org>wrote:
>
>>
>> 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.
Posted by Kay Schenk <ka...@gmail.com>.
On Mon, Mar 19, 2012 at 5:31 PM, Ariel Constenla-Haile
<ar...@apache.org>wrote:
>
> 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.
Posted by Ariel Constenla-Haile <ar...@apache.org>.
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
Re: update service - proposal for temporary solution until AOO 3.4 is released.
Posted by Kay Schenk <ka...@gmail.com>.
On Mon, Mar 19, 2012 at 1:40 PM, Ariel Constenla-Haile
<ar...@apache.org>wrote:
> 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.
Posted by Ariel Constenla-Haile <ar...@apache.org>.
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
Re: update service - proposal for temporary solution until AOO 3.4
is released.
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi Kay,
On 19.03.2012 17:04, Kay Schenk wrote:
> On Mon, Mar 19, 2012 at 5:00 AM, Oliver-Rainer Wittmann<
> orwittmann@googlemail.com> wrote:
>
>> Hi
>>
>>
>> On 18.03.2012 22:14, Kay Schenk wrote:
>>
>>> On Sun, Mar 18, 2012 at 10:10 AM, Kay Schenk<ka...@gmail.com>
>>> wrote:
>>>
>>>
>>>>
>>>> On Thu, Mar 15, 2012 at 5:03 AM, Oliver-Rainer Wittmann<
>>>> orwittmann@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.**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_release<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.**ope**noffice.org/****
>>>>> ProductUpdateService/check.**<http://openoffice.org/**ProductUpdateService/check.**>
>>>>> Update<http://update36.**services.openoffice.org/**
>>>>> ProductUpdateService/check.**Update<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://**installat**ion.openoffice.org/**<http://installation.openoffice.org/**>
>>>>> description<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<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<http://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.
>>
>
> 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 ;-) ]
Best regards, Oliver.
Re: update service - proposal for temporary solution until AOO 3.4 is released.
Posted by Kay Schenk <ka...@gmail.com>.
On Mon, Mar 19, 2012 at 5:00 AM, Oliver-Rainer Wittmann <
orwittmann@googlemail.com> wrote:
> Hi
>
>
> On 18.03.2012 22:14, Kay Schenk wrote:
>
>> On Sun, Mar 18, 2012 at 10:10 AM, Kay Schenk<ka...@gmail.com>
>> wrote:
>>
>>
>>>
>>> On Thu, Mar 15, 2012 at 5:03 AM, Oliver-Rainer Wittmann<
>>> orwittmann@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.**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_release<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.**ope**noffice.org/****
>>>> ProductUpdateService/check.**<http://openoffice.org/**ProductUpdateService/check.**>
>>>> Update<http://update36.**services.openoffice.org/**
>>>> ProductUpdateService/check.**Update<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://**installat**ion.openoffice.org/**<http://installation.openoffice.org/**>
>>>> description<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<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<http://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.
>
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?
--
----------------------------------------------------------------------------------------
MzK
"Follow your bliss."
-- attributed to Joseph Campbell
Re: update service - proposal for temporary solution until AOO 3.4
is released.
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi
On 18.03.2012 22:14, Kay Schenk wrote:
> On Sun, Mar 18, 2012 at 10:10 AM, Kay Schenk<ka...@gmail.com> wrote:
>
>>
>>
>> On Thu, Mar 15, 2012 at 5:03 AM, Oliver-Rainer Wittmann<
>> orwittmann@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_release<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<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<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.
>
>
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.
Posted by Kay Schenk <ka...@gmail.com>.
On Sun, Mar 18, 2012 at 10:10 AM, Kay Schenk <ka...@gmail.com> wrote:
>
>
> On Thu, Mar 15, 2012 at 5:03 AM, Oliver-Rainer Wittmann <
> orwittmann@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_release<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<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 <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.**Update<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<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<http://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.
Posted by Kay Schenk <ka...@gmail.com>.
On Thu, Mar 15, 2012 at 5:03 AM, Oliver-Rainer Wittmann <
orwittmann@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_release<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<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 <http://installation.openoffice.org/description>">
> </inst:description>
>
> Can someone implement the redirect?
> May be http://www.openoffice.org/**ProductUpdateService/check.**Update<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<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<http://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.
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
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.
Re: update service - further information for such a service
Posted by Kay Schenk <ka...@gmail.com>.
On Thu, Mar 15, 2012 at 5:52 AM, Rob Weir <ro...@apache.org> wrote:
> On Thu, Mar 15, 2012 at 7:47 AM, Oliver-Rainer Wittmann
> <or...@googlemail.com> 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, ...?
> >
>
> My opinion:
>
> This is an example of a "low rate of change" application. The data
> changes every few weeks or months, not daily or hourly. It is also a
> high traffic service, especially when we have millions of clients
> doing automatic update checks. So a static file is probably better
> for server load/performance.
>
> I wonder if the static XML file could be automatically generated via a
> script? Maybe part of our release script? (I assume we'll eventually
> have a release script that deals with cutting RC's, doing the code
> signing, etc.)
>
I need to check Oliver's updates to our documentation, but my thought was
in agreement with what your propose Rob (if possible) - - at least for the
base product, generate the XML nightly(?) for available updates. I hit a
wall in many areas, not the least of which is the actual format of the XML
feed. Then, we get to deal with "fact finding" -- what do we have and how
do we determine products, buildids, etc. From what I could gather so far,
there was some sort of "backend product" that required manual entry of
these kinds of params. Assuming we could actually manually create (now)
such and XML feed, at some point we would need to spend time in (perhaps)
standardizing on build names etc to do something more or less
"automatically", and by this I mean, not a web service but just a feed
generation.
Then, of course there's the extension updates....somewhat the same,
somewhat different.
> > 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
>
--
----------------------------------------------------------------------------------------
MzK
"Follow your bliss."
-- attributed to Joseph Campbell
Re: update service - further information for such a service
Posted by Rob Weir <ro...@apache.org>.
On Thu, Mar 15, 2012 at 7:47 AM, Oliver-Rainer Wittmann
<or...@googlemail.com> 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, ...?
>
My opinion:
This is an example of a "low rate of change" application. The data
changes every few weeks or months, not daily or hourly. It is also a
high traffic service, especially when we have millions of clients
doing automatic update checks. So a static file is probably better
for server load/performance.
I wonder if the static XML file could be automatically generated via a
script? Maybe part of our release script? (I assume we'll eventually
have a release script that deals with cutting RC's, doing the code
signing, etc.)
> 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
Re: update service - further information for such a service
Posted by Joost Andrae <Jo...@gmx.de>.
Hi,
> All seems right. One missing point is the query part of the URL,
> a non-WNT feature related to the package format, see
> http://svn.apache.org/viewvc/incubator/ooo/trunk/main/scp2/source/ooo/common_brand.scp?revision=1296424&view=markup#l1031
>
> ${UPDATEURL}?pkgfmt=<pkgformat>
>
> A web service should analyze the query string, pkgfmt can be rpm or deb
> (in a common Linux install set).
>
the former Product Update Service differentiated between update URLs
pointing to a binary location and update notifications that pointed to a
landing page. In case of a binary location the pkg format is used to
differ between sh (Self extracting binary as UNIX shell script), rpm and
deb (Linux), dmg (Mac) and exe (Win32) for binaries. The name scheme of
binary distributions is also important to get things automated.
see http://www.openoffice.org/development/releases/filenames
Kind regards, Joost
Re: update service - further information for such a service
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 15.03.2012 14:20, Ariel Constenla-Haile wrote:
> Hi Oliver,
>
> On Thu, Mar 15, 2012 at 12:47:41PM +0100, 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, ...?
>
> All seems right. One missing point is the query part of the URL,
> a non-WNT feature related to the package format, see
> http://svn.apache.org/viewvc/incubator/ooo/trunk/main/scp2/source/ooo/common_brand.scp?revision=1296424&view=markup#l1031
>
> ${UPDATEURL}?pkgfmt=<pkgformat>
>
> A web service should analyze the query string, pkgfmt can be rpm or deb
> (in a common Linux install set).
>
Thanks for the pointer - I will update the wiki.
For a static approach it would mean that we would not have the possibility to
provide a download link for Linux platforms. In this case we could only provide
a download website.
For the MacOS X platform we only have <pkgformat>=dmg. Right?
If yes, a static approach could also provide a download link.
Best regards, Oliver.
>
>> 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
>
> Regards
Re: update service - further information for such a service
Posted by Ariel Constenla-Haile <ar...@apache.org>.
Hi Oliver,
On Thu, Mar 15, 2012 at 12:47:41PM +0100, 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, ...?
All seems right. One missing point is the query part of the URL,
a non-WNT feature related to the package format, see
http://svn.apache.org/viewvc/incubator/ooo/trunk/main/scp2/source/ooo/common_brand.scp?revision=1296424&view=markup#l1031
${UPDATEURL}?pkgfmt=<pkgformat>
A web service should analyze the query string, pkgfmt can be rpm or deb
(in a common Linux install set).
> 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
Regards
--
Ariel Constenla-Haile
La Plata, Argentina