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 a OOo 3.3 update service
Date Fri, 18 May 2012 20:55:59 GMT
On Fri, May 18, 2012 at 1:09 AM, Oliver-Rainer Wittmann <
orwittmann@googlemail.com> wrote:

> Hi,
>
>
> On 17.05.2012 03:13, Kay Schenk wrote:
>
>> On Wed, May 16, 2012 at 1:44 PM, Oliver-Rainer Wittmann<
>> orwittmann@googlemail.com>  wrote:
>>
>>  Hi,
>>>
>>> On 16.05.2012 21:58, Kay Schenk wrote:
>>>
>>>
>>>>    [snip]
>>>>>>
>>>>>
>>>>>
>>>>>  One of the problems we will run into, esp for Linux (I don't know
>>>>> about
>>>>>
>>>>>> other platforms) is that the user has a appended "pkgfmt" already
on
>>>>>> the
>>>>>> update URL, so in my experimenting, the update call failed because
an
>>>>>> acceptable package was not found.
>>>>>>
>>>>>>
>>>>>  From my point of view this should not be a problem as it seems that
>>>>> the
>>>>> HTTP server neglects the URL query part in such a "static" case.
>>>>> I am not an expert here, please correct me if I am wrong.
>>>>>
>>>>>
>>>> well, I'll try it again...I have several versions to play with...I seem
>>>> to
>>>> recall I had to manually delete the pkgfmt business and then I got it to
>>>> work.
>>>>
>>>>
>>>>  I have recently tested on Ubuntu with an old developer snapshot of AOO
>>> 3.4.
>>> It just worked fine, even with an update URL having the query part.
>>>
>>>
>> OK...I recall I had to take this off and then it did work with getting me
>> a
>> URL page.
>>
>>
> I am not sure, if we both about the same.
> Thus, please let me in more detail describe what I am observing:
> For the "static" solution we would have a corresponding HTTP resource (our
> XML document) at URL X. I see that the HTTP GET requests made by the update
> functionality in AOO 3.4 and OOo 3.3 to URL X?pkgformat=deb are answered by
> the HTTP server. The response from the HTTP server contains the requested
> HTTP resource - in our case the XML document.
> Then the XML document is parsed by the update functionality in AOO 3.4
> resp. OOo 3.3. Two cases needs to be distinguish here:
> (1) XML document is in the simple form - only containing XML element
> <inst:description> with corresponding childs.
> (2) XML document is in the atom feed form
>
> In case (1) the update functionality checks the following three conditions:
> (a) <inst:os> content matches the one of the installed version
> (b) <inst:arch> content mathes the one of installed version
> (c) <inst:buildid> contant - BuildID of newer version - is greater than
> the BuildID of the installed version.
> Possible values for <inst:os> and <inst:arch> can be found in [1].
> If the conditions hold further information are read - <inst:version> and
> <inst:update> - and the user is presented the information that an update is
> available together with the update URL.
> If the conditions do not hold - e.g. empty <inst:description> element the
> user is presented the information that installed version is up to date.
>
> In case (2) the update functionality searches for entries which matches
> the condition that attribute term of element <category> matches the one of
> installed version. Then action as in case (1) are performed on each entry
> until an entry matches the above conditions.
>
> If, I understand your observations correct, you need to remove the query
> part from the update URL in order to assure that the update functionality
> recieves the XML document. Is this correct?
>

well this is what I remember...yes. After I did that, I did get the "go to
URL" approach to work. I was running 3.3, can't recall what the build
number was.


>
> [1] https://svn.apache.org/repos/**asf/incubator/ooo/trunk/main/**
> sal/rtl/source/macro.hxx<https://svn.apache.org/repos/asf/incubator/ooo/trunk/main/sal/rtl/source/macro.hxx>
>
>
>>  When I browse to http://update36.services.**ope**noffice.org/**<http://openoffice.org/**>
>>> ProductUpdateService/check.****Update?pkgformat=deb<http://**
>>> update36.services.openoffice.**org/ProductUpdateService/**
>>> check.Update?pkgformat=deb<http://update36.services.openoffice.org/ProductUpdateService/check.Update?pkgformat=deb>
>>> >**using the FireFox it provides me the content of the XML document.
>>>
>>> BTW, I have already updated the XML document as you suggested. As I
>>> forgot
>>> to include an entry for Linux 32bit in my first try you may be hit my
>>> first
>>> XML document.
>>>
>>>
>>>  I'll get back to you on this later today.
>>>
>>>>
>>>>
>>>>  Ok, thanks.
>>>
>>
>>
>> OK, well since I am at 3.4., I can't help much with this without editing
>> the XML doc yo have out there I'm afraid, so I will take your word for
>> what
>> you say works and just hope we can get on with things.
>>
>>
> Yes. When you are testing with a released AOO 3.4 you at least need to
> increase the value of <inst:buildid> in the XML document to get the
> information from the update functionality that an update is available.
>
>
>
>>
>>>
>>>
>>>  I think I will make a discussion thread to totally ditch the pkgfmt
>>>> business
>>>> from Linux update URLs. It would considerably simplify our lives.
>>>>
>>>>
>>>>  Do you mean for future versions of AOO?
>>>
>>>
>> yes...this would be best I think. Installing on Linux automatically can be
>> tricky if you're not root anyway. No harm in just shuttling folks to a
>> page
>> to choose something and then do the install in my mind.
>>
>>
> I never tried the automatic installation on Linux. I will hae a look in my
> Ubuntu VM which has OOo 3.3 installed.
>
>
>
>>
>>  This may be possible, because this information could also "coded" into
>>> the
>>> "User-Agent" field of the HTTP GET request.
>>>
>>>
>> I don't get your meaning here. Sorry.  ????
>>
>>
> The HTTP GET request contains information about the installed version
> making the request. The needed package format is currently "coded" as the
> URL query part. But, it could be also "coded" in the HTTP "User-Agent"
> field.


How would we do that?


>
>  OK, the next step, which we should deal with very cautiously given my past
>> experiment, is to get infra to redirect update36.services.openoffice.**
>> org <http://update36.services.openoffice.org> to
>> the web server IP address.
>>
>>
> From my point of view we only should redirect the update URL of OOo 3.3 -
> namely update36..... If it works fine, we can think of redirecting further
> update URLs from former versions.
>

Right--and that was my thought as well. This is why I started out havign
infor redirect update30, which, at it turns out, was a HUGE mistake because
it didn't work the same as the future versions -- it did POST calls instead
of GET.


> My personal opionion is that such redirects are not needed - but this is
> only my view.


well, who knows. We could do it, and potentially, it would do no harm.


>
>
>  It would be better if we could just try this with a very limited set of
>> updates for the time being...maybe just 32 bit Linux German, for example,
>> and take out the others for a bit and see what happens.
>>
>> The other thing is since we're still in the midst of the traffic for the
>> new release, it would be better to wait at least another week. I know
>> you've been after this for a while, and I completely understand, but well,
>> results were REALLY disastrous with the update30 re-route -- I kid you
>> not.
>> Within 2 hours it incapacitated the Apache web server with the bad "post"
>> calls -- I mean ALL of it -- all sites, and the redirect had to be backed
>> out. I know we use "get" now and not post, but who would know this?
>>
>>
> Yes, we should wait for at least one week to establish the update service
> for OOo 3.3. And then only for OOo 3.3


I have a suggestion in the meantime, since I take it we would like some
additional "in house" testing.

You could post a new thread asking for testers who currently still have a
3.3. version (or maybe they have friends that do), tell them they'll need
to do a local redirect -- via local /etc/hosts -- from
update36.services.openoffice.org, to the web server IP, and then have them
do the "Check Update" and see what happens.

I actually tried to convince Windows friends to do this when I was working
on this in early spring, but I just couldn't convince them they actually
had an /etc/hosts and this would do no harm! :/

Maybe you'll have better luck.


>
>  Maybe infra has like a different server we could use -- with a web server
>> running on it, but not the main server. I'll try to find out tomorrow on
>> #asinfra or you could get on there and find out.
>>
>>
>>
> That is great that you are getting in contact with ASF infra regarding
> this issue. Thx.
>

yes, I promise I will...but probably not until Monday.



>
> Best regards, Oliver.
>

OK, thanks for all this.

ps. If you figure out a way to do a generic URL redirect for all platforms
and variants, let us know. This could be VERY helpful.


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

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

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