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 Wed, 23 May 2012 17:44:31 GMT


On 05/23/2012 02:16 AM, Oliver-Rainer Wittmann wrote:
> Hi,
>
> On 22.05.2012 18:21, Kay Schenk wrote:
>> On Tue, May 22, 2012 at 6:21 AM, Oliver-Rainer Wittmann<
>> orwittmann@googlemail.com> wrote:
>>
>>> [snip]
>>>
>>>>
>>>> I would prefer the "static" solution as a short-term one which could be
>>>> working
>>>> next week.
>>>> For the "dynamic" solution a script is needed. I have no experience in
>>>> programming such a script. Is there a volunteer who would take over
>>>> this
>>>> task?
>>>>
>>>
>> I don't have any ideas at all in what would be included in such a
>> script...so no help from me. And, I wonder if something like that was
>> ever
>> in operation. With no knowledge, I can't say.
>>
>
> I assume that there were some server-side logic, but I am not sure.
> This logic would had investigated the HTTP GET request header fields
> "User-Agent" and "Accept-Language" to identify the OOo installation,
> e.g. German OOo 3.1 running on MacOS X.

hmmmm...well I assumed all this was taken care by OOo itself in terms of 
identification combined with the XML feed in check.Update. So, I was not 
under the impression there was server-side involved.

> Then, I assume, it looked into its database for the newest OOo version
> for such an OOo installation. If it founds a newer version, e.g. German
> OOo 3.3 for MacOS X it assembles a corresponding XML document containing
> the data about this newer version. This XML document was then delivered
> as the HTTP GET response.
>
>>>>
>>>> Any thoughts/comments/**improvements/changes/...?
>>>>
>>>>
>>>>
>>> It looks like we can go with the "static" solution as a short-term
>>> solution.
>>>
>>
>> Sounds good. this is reasonable and should work assuming infra can deal
>> with handling the "pkgfmt" bits for Linux, for example.
>>
>
> If we want to provide a direct download link for OOo 3.3 installation on
> Linux, this special handling will be needed.
> If we only want to provide a web page link from which the user have to
> manually download the needed package, this special handling won't be
> needed.

OK, I'll trust what you say here. I guess we'll see what happens for 
others. We should just plan on directing Linux folks to a web page.

>
>>
>>> Thus, I will do the following:
>>> - Creation of a complete XML document
>>> - Include entries for at least one languages for which we have currently
>>> no AOO 3.4 installation package.
>>> - Providing the XML document and possible variants on [3] for testing
>>> and
>>> verification.
>>> - Call for volunteers to test the XML document at [3].
>>> - Integrate feedback, if we want to have direct download links or
>>> links to
>>> a certain existing web page for manual download.
>>>
>>
>> I don't understand this one. Initiate update vs letting user choose and
>> then do installation on their own?
>>
>
> The XML document will contain element <inst:update>. Its attribute "src"
> will contain an URL. Its attribute "type" will determine, if the update
> function in OOo 3.3 will interpret the URL as an direct download link or
> as a link to a web page. Depending on the type the update function
> provides the user the function to trigger the download or to open the
> URL in the default browser.
>
> Rob and Roberto - as far as I have understand - were in favor of
> providing a link to a web page. I am completely open here. Thus, I think
> I will provide different variants of the XML document for testing.
>
>
> Best regards, Oliver.

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

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

Mime
View raw message