Mailing-List: contact dev-help@openoffice.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openoffice.apache.org
Received-SPF: pass (athena.apache.org: domain of jogischmidt@gmail.com
 designates 209.85.214.42 as permitted sender)
Message-ID: <51C077C4.5060809@gmail.com>
Date: Tue, 18 Jun 2013 17:07:48 +0200
From: =?UTF-8?B?SsO8cmdlbiBTY2htaWR0?= <jogischmidt@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: dev@openoffice.apache.org
Subject: Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
 help needed
References: <51A4C8D8.5000406@googlemail.com>
 <CAP-ksogEAZ7WX6WwtTBzxkxrmjnHj+8GswiPQWi29ijGXSM8eQ@mail.gmail.com>
 <51A6159B.80403@googlemail.com> <51AB29D9.6020108@apache.org>
 <51AC5806.9000004@googlemail.com>
 <000c01ce6148$a23ab8a0$e6b029e0$@zybura.com>
 <1D35A2254CFC4DD3B23B9725BEA40777@gmail.com> <51AE4768.7070001@laposte.net>
 <95B5D6E9B67E4D4591709E8F00B32200@gmail.com> <51AE5C0E.7070401@laposte.net>
 <51AF3C35.8060309@googlemail.com> <51AF9B1D.90804@laposte.net>
 <51BA3D50.2070705@apache.org> <51BEC0F0.3010600@googlemail.com>
 <51C00BBB.6090406@apache.org> <51C01192.3030203@googlemail.com>
 <CAP-ksoipzu1hJVFX84fs+0oYydOsjvR2O2OX4jDC9VgWq3Tykw@mail.gmail.com>
 <51C04FC3.8010706@googlemail.com>
In-Reply-To: <51C04FC3.8010706@googlemail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 6/18/13 2:17 PM, Oliver-Rainer Wittmann wrote:
> Hi,
> 
> On 18.06.2013 13:36, Rob Weir wrote:
>> On Tue, Jun 18, 2013 at 3:51 AM, Oliver-Rainer Wittmann
>> <orwittmann@googlemail.com> wrote:
>>> Hi,
>>>
>>>
>>> On 18.06.2013 09:26, Andrea Pescetti wrote:
>>>>
>>>> On 17/06/2013 Oliver-Rainer Wittmann wrote:
>>>>>
>>>>> I want to let you know that I am currently working on the migration of
>>>>> AOO 3.4.x/OOo 3.x user profiles to AOO 4.0. I am also including the
>>>>> migration of extensions.
>>>>> I am currently not planning to adjust any of the mentioned strings
>>>>> as I
>>>>> think it is too late for its translation.
>>>>
>>>>
>>>> Is this safe? In a typical scenario, then, a user would have some
>>>> extensions installed and he would see them imported in 4.0 without
>>>> being
>>>> warned about possible compatibility problems. Most of the extensions do
>>>> not have a maxversion indication, so OpenOffice 4.0 will try and
>>>> install
>>>> them anyway, but some might be broken. And then the user is left alone
>>>> in updating his extensions (which in theory he should be prompted to do
>>>> after installation, assuming this mechanism is restored), but he
>>>> wouldn't have a way to go back before it's too late.
>>>>
>>>
>>> I had a close look at the functionality to 'migrate the extensions
>>> from a
>>> former user profile' and from my point of view we should give it a try.
>>>
>>> The function did the following:
>>> It looks for the extensions which are installed for the user. These are
>>> found in the former user profile. No shared-installed, bundled or
>>> pre-registered extensions are considered. The found user-installed
>>> extensions which are not on the blacklist are installed with the same
>>> mechanism which is used when the users triggers in the installation.
>>> I am activating an user interaction in case that an extension is already
>>> installed - the same user interaction which is used when the user
>>> triggers
>>> the installation of an already installed extension.
>>>
>>> On the blacklist will be the Presenter Screen and the Presentation
>>> Minimizer
>>> as they are now integrated into OpenOffice.
>>>
>>
>> Is the blacklist a static list? Or is it something that can be
>> retried/updated from the website?
>>
> 
> The blacklist is part of our source code. These are corresponding
> entries in a XCU file - namely
> main/officecfg/registry/data/org/openoffice/Setup.xcu
> Have a look at my commit - revision 1494066 [1]. Search for
> 'ExcludedExtensions'
> 
> [1] http://svn.apache.org/r1494066
> 
>> If we can make the blacklist be "live" in a document that we can
>> update, this is like maintaining our own max version field for the
>> cases where the extension author neglected to do so.
>>
> 
> Such a feature is possible.
> It could be corresponding XML feed which OpenOffice could be accessed
> via the Internet - like the XML feed for the update service.

before we implement further features in the context of the extension
manager I would like to propose a complete review of the current design.

That means analyze what we have today and we want to provide reliable
tomorrow and rework the code according the new requirements. This means
mainly a simplification of the current implementation to make it more
better maintainable, more robust and easier to understand.

The first feature that I would drop is the live deployment that is a
nice feature but not worth the complexity that it brings in the code. A
clean office restart after the installation should be no problem.

We need also a better and cleaner way to handle and deploy bundled
extensions like dictionaries etc. I would like to avoid the installation
in the user home directory...

Many more things come into my mind.

The blacklist was of course not intended to be used to manage a big list
of extensions.

Juergen

> 
> Best regards, Oliver.
> 
>> -Rob
>>
>>
>>>
>>>
>>>>> If my tests work fine, I will check-in the changes this week. If we
>>>>> will
>>>>> include these changes into our AOO 4.0 release, I will help to update
>>>>> the above wiki page.
>>>>
>>>>
>>>> Let's keep them documented and see. Remember that we learned so far
>>>> that
>>>> a random user will manage to reinstall but not to do anything more
>>>> elaborated, so if uninstallation/installation does not bring up a "Do
>>>> you want to reset your profile?" dialog we still have a usability
>>>> problem (which of course is not a regression, it's been there forever).
>>>>
>>>
>>> Agreed.
>>>
>>>
>>> Best regards, Oliver.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>>
>>
>>
>> -- 
>> Opinions expressed in this communication reflect the author's
>> individual personal view, not necessarily that of an amorphous
>> collective.  The above statements do not reflect an official position
>> of any organization, corporation, religion (organized or disorganized)
>> or national football association.  The contents of said note are not
>> guaranteed to have been spell checked, grammar checked or reviewed for
>> metrical infelicities.  The contents of this post may not be suitable
>> for those whose native language is not logic.  Caution should be
>> exercised when operating heavy machinery when reading this note, or
>> even when not reading it.  Seriously, heavy machinery is dangerous.
>> Be careful.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org