fdo#51004: some progress and 10 years old bug pending

[Lionel Elie Mamane]

On Tue, Oct 16, 2012 at 08:07:53AM +0200, David Ostrovsky wrote:
> Am 15.10.2012 09:50, schrieb Lionel Elie Mamane:

>>>done:https://gerrit.libreoffice.org/#/c/841/

>>>> I wasn't sure what would be the best way to differentiate between test
>>>> and production case, so i abused driver url...
>>>> It would be nice if someone could review it.

>> Rather than special-case the test case, how about extend the
>> production case so that it can be directed to an arbitrary file?

> sounds reasonable. With that in place LO would have even more
> features as the thunderbird itself

Oh, that's OK, we don't have to keep to any "non-compete" agreement
with Mozilla :-)

> At least I am not aware how you can open backup address book in
> thunderbird?

> Only thing that worked for me is to replace the deafult one from the
> user profile.

There is a bit better. In Icedove 3.0.11:

Press button "Address Book" or CTRL-SHIFT-b or menu tools / Address Book
In new window, menu File / New / Address Book
Enter name "My backup from tape/other computer/..."
OK
This creates a new .mab file; overwrite *that* one instead of the
default one :)


This begs the question: can our Icedove/Thunderbird integration open
these other .mab files "easily"? Does the user have to give the
filename (abook-1.mab, abook-2.mab, abook-3.mab, ...) or the name?
Sadly, the name-to-filename mapping is stored in prefs.js:

user_pref("ldap_2.servers.jsddshjds.description", "my backup from tape 12/2/2012");
user_pref("ldap_2.servers.jsddshjds.dirType", 2);
user_pref("ldap_2.servers.jsddshjds.filename", "abook-1.mab");

Which means yet another file to parse for the full completely
user-friendly case of "show the same list as Thunderbird, let the user
choose-by-click one of them" :-| And also that's even more of an
"internal implementation detail of Icedove/Thunderbird" than the .mab
file format is.

If we do that, we should store (in the sdbc: URL) the *internal* name
(in my example: "jsddsgjds"), which is basically (an unification /
drop spaces version of) the name the address book had at creation
time, but that does not change when the address book is renamed.

Or (I'm thinking out loud here) the filename, e.g. abook-4.mab... That
also does not change, but may be easier to use. On the other hand, a
disadvantage is that if the address book is deleted, the filename gets
recycled by the next address book to be created, so suddenly we'd be
silently opening another address book.

> But take into considreation that on windows old mozab driver still
> used.

Sorry, I didn't follow this story closely. Why?

> So if we are going to extend the databse creation UI and introduce
> new path input field it should also work for old mozab driver
> (unless we sort that platform out).

Naively, maintaining a single driver looks easier than maintaining two
drivers.

>> for example:

>> "sdbc:address:thunderbird" would get the abook.mab from the default
>> profile, but "sdbc:address:thunderbird:/home/user/backup/blah.mab"
>> would open file /home/user/backup/blah.mab

>> Actually, I can see another specific case, which is to access other
>> profiles than the default. It would be nice not to hard-code the full
>> path there, so maybe something like

>> sdbc:address:thunderbird:profile:FOO

>> to open the profile called "FOO" in profiles.ini?

>> In connectivity/source/drivers/mork/MConnection.cxx, I see:

>> OUString defaultProfile = m_pProfileAccess->getDefaultProfile(::com::sun::star::mozilla::MozillaProductType_Thunderbird);

>> Not sure what object m_pProfileAccess is, but if it has something like
>> a method
>> getNamedProfile(::com::sun::star::mozilla::MozillaProductType_Thunderbird, "FOO")
>> we should be in business?

> Interesting point, but how one should extend the profile? Ideas?

I'm not sure what you mean by "extend the profile". You mean the
m_pProfileAccess object? Well, it already parses Icedove/Thunderbird's
profiles.ini to get the default profile, so it should be rather easy
to extend it to get other profiles, if necessary.

-- 
Lionel