On Wed, May 16, 2012 at 9:26 PM, Rob Weir <robw...@apache.org> wrote:
> On Wed, May 16, 2012 at 3:16 PM, Oliver-Rainer Wittmann > <orwittm...@googlemail.com> wrote: > > Hi > > > > > > On 16.05.2012 20:47, Oliver-Rainer Wittmann wrote: > >> > >> On 16.05.2012 19:38, Kay Schenk wrote: > >>> > >>> On Tue, May 15, 2012 at 11:37 PM, Oliver-Rainer Wittmann< > >>> orwittm...@googlemail.com> wrote: > >>>> > >>>> On 15.05.2012 20:45, Oliver-Rainer Wittmann wrote: > >>>>> > >>>>> Am 15.05.12 16:11, schrieb Rob Weir: > >>>>> > >>>>>> On Tue, May 15, 2012 at 8:11 AM, Oliver-Rainer Wittmann > >>>>>> <orwittm...@googlemail.com> wrote: > >>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> From my point of view it would make sense to reactivate a simple > >>>>>>> update > >>>>>>> service for AOO 3.4. > >>>>>>> > >>>>>>> The update URL for AOO 3.4 is: > >>>>>>> > >>>>>>> http://update38.services.** > openoffice.org/**ProductUpdateService/check. > >>>>>>> > >>>>>>> **Update< > http://update38.services.openoffice.org/ProductUpdateService/check.Update> > >>>>>>> > >>>>>>> (plus a query part ?pkgfmt=<pkgformat> for non-Windows platforms) > >>>>>>> > >>>>>>> As this URL resolves to nothing, the user currently gets the > >>>>>>> following > >>>>>>> response from the update functionality in AOO 3.4: > >>>>>>> Status: Checking for an update failed. > >>>>>>> Description: General Internet error has occurred. > >>>>>>> > >>>>>>> I propose provide the following XML document when a HTTP GET > request > >>>>>>> to > >>>>>>> the > >>>>>>> above given URL is made: > >>>>>>> <?xml version="1.0" encoding="UTF-8"?> > >>>>>>> <inst:description > >>>>>>> > >>>>>>> xmlns:inst="http://**installation.openoffice.org/**description< > http://installation.openoffice.org/description> > >>>>>>> > >>>>>>> "> > >>>>>>> </inst:description> > >>>>>>> > >>>>>>> Kay already made such an XML document available at: > >>>>>>> > >>>>>>> http://www.openoffice.org/**ProductUpdateService/check.**Update< > http://www.openoffice.org/ProductUpdateService/check.Update> > >>>>>>> > >>>>>>> > >>>>>>> This response would allow the update functionality in AOO 3.4 to > >>>>>>> return > >>>>>>> to > >>>>>>> the user that the version is up to date. > >>>>>>> > >>>>>>> Thus, to reactivate an working update service for AOO 3.4 a > >>>>>>> redirection > >>>>>>> is > >>>>>>> needed. > >>>>>>> > >>>>>>> > >>>>>> Are proposing that we just have a static XML file and redirect the > >>>>>> requests so it loads that static file? > >>>>>> > >>>>>> > >>>>> Yes, as a short-term and fast solution. > >>>>> > >>>>> I can see that as being a useful short-term solution. But soon we'll > >>>>>> > >>>>>> need some more complicated logic, right? For example, when we enable > >>>>>> the 3.3. update check, we'll need to know that updates are available > >>>>>> for some languages, but not others. Can we do that all with > >>>>>> redirection to static files? Or do we need server-based logic, i.e., > >>>>>> a cgi script? > >>>>>> > >>>>>> > >>>>> Static files would be possible, because each version has its own > update > >>>>> service > >>>>> URL, but it would be not the best solution for the long-term. > >>>>> Thus, some server-based logic would make sense. > >>>>> > >>>>> If we're going to need a cgi script in the end, I wonder if it makes > >>>>>> > >>>>>> sense to start with one now? We could have a simply script that > today > >>>>>> just always points to the "no update available" XML for AOO 3.4. But > >>>>>> then we make it more complicated as we go. > >>>>>> > >>>>>> > >>>>> I am currently in preparation of a proposal for an update service for > >>>>> OOo > >>>>> 3.3 > >>>>> installations. Here, I can/will demonstrate how a server-based logic > >>>>> would look > >>>>> like. > >>>>> > >>>>> Can somebody make this happen? > >>>>>>> > >>>>>>> I have to admit that do not have the knowledge to do it on my own. > >>>>>>> > >>>>>>> > >>>>>> If we just redirect to a static file, I think you can just enter a > >>>>>> JIRA request for Infra. If we go with a cgi script then we need > >>>>>> someone to develop that script first. > >>>>>> > >>>>>> > >>>>> If nobody objects, I would go for this short-term and static approach > >>>>> and > >>>>> would > >>>>> ask via JIRA request for Infra, if the redirect to the already > existing > >>>>> static > >>>>> file can be established. > >>>>> > >>>>> > >>>> I will use issue 119361 - https://issues.apache.org/ooo/** > >>>> > >>>> show_bug.cgi?id=119361< > https://issues.apache.org/ooo/show_bug.cgi?id=119361>- > >>>> to track the progress on this task. > >>>> > >>>> Best regards, Oliver. > >>>> > >>> > >>> > >>> OK, and a very short update on this. > >>> > >>> I tried to deal with this and continually ran into issues. > >>> > >>> At the simplest, I tired to make up a "generic" update for maybe all > >>> platforms and languages that would just take them to a page to choose > an > >>> update -- basically our download/other.html at this point. > >>> > >> > >> I think here some server-side script is needed. > >> A complete "generic" solution which provides a "static" XML document is > to > >> hard > >> figure out. > >> > >>> However, if you exclude the platform and other particulars in a very > >>> simple > >>> XML file, nothing happens -- in other words, the URL is just ignored > and > >>> you get a "no updates" message. This is what is in: > >>> /projects/update36/ProductUpdateService/check.update > >>> now. > >> > >> > >> That is right. > >> The update functionality searches in the returned XML for its operating > >> system > >> and its architecture and a buildid which is greater than its own. If it > >> does not > >> found it, it assumes that no newer version is available. > >> > >>> > >>> Also, life is complicated by appending the "pkgfmt " on update strings > in > >>> > >>> <AOO install directory>/program/versionrc (for linux...name will vary > >>> depending on OS) > >>> > >> > >> I will do some further checks with the URL query part. > >> > > > > For a "static" solution the URL query part should not be a problem. It > seems > > to be completely neglected by the HTTP server. > > I have currently some static test XML documents on > > http://people.apache.org/~orw/testupdateservice/ > > The XML documents are included in the HTTP GET response regardless of the > > URL query part. > > As I am not an expert of HTTP and HTTP server, please correct me, if I am > > wrong here. > > > > I'd keep it simple. > > Two main tasks: > > 1) Identify whether there is an update available for the user's current > install > > 2) Direct the user to that update > > I'd keep #2 really really simple. We already know there is an update. > We already have logic on http://download.openoffice.org for finding > the correct download. So for #2 just always send the user to > http://download.openoffice.org. > > That approach even does magical things. For example, in the future, > the user might be running OpenOffice on a 64-bit Windows, but they are > running 32-bit OO, since that is all that exists. But when we come > out with a new 64-bit of AOO 3.x, the logic on > http://download.openoffice.org will automatically suggest it. Ditto > for better language support. Someone might be running Spanish AOO 3.4 > but then decide to upgrade to Catalan AOO 3.X (assuming it is > available). > Is this what we plan to do for OOo 3.3 users too? > > Getting the user to the download site also help us engage them more > with the ecosystem, whether signing up for announcement list, > following us on Twitter, showing how they can get involved in the > project, etc. It is almost always a good idea to send the user to the > website. > In this case we might be serving those downloads too. Considered the amount of potential users, we'd like to sort out plan as we did for AOO 3.4, so that we can watch traffic and mirror stability. Roberto > > -Rob > > > Best regards, Oliver. > -- ==== This e- mail message is intended only for the named recipient(s) above. It may contain confidential and privileged information. If you are not the intended recipient you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and delete the message and any attachment(s) from your system. Thank you.
