incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kay Schenk <kay.sch...@gmail.com>
Subject Re: [UPDATE SERVICE] proposal for a AOO 3.4 update service
Date Fri, 18 May 2012 20:44:57 GMT
On Wed, May 16, 2012 at 12:26 PM, Rob Weir <robweir@apache.org> wrote:

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

Hi Rob --

Well as nice as this sounds, we are restrained by the way the update
service is implemented in current code, I believe.  I'm fairly certain,
unless someone else can chime in about this, that we're restricted to
returning JUST an XML feed at this point.  In future releases, something
else might be proposed.

 I think doing much of anything server-side, well unless we could do a
"catch all" generic url (for all platforms and all langugages..) that then
runs a cgi, that DOES something.  hmmmm...

I don't know, it could have promise. I wasn't successful in the "do all for
everyone" approach. Maybe there's a trick to specifiying this.



> > Best regards, Oliver.
>



-- 
----------------------------------------------------------------------------------------
MzK

"The reports of my death are greatly exaggerated."
                                 -- Mark Twain

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message