Issue 34909

Michael, is it possible that Evolution does not contain the address book
exporter script anymore? I know it has a separated address backend - perhaps the
exporter script was removed in this move?

Frank, sadly I don't keep a careful-enough eye on the evo. development in this
area it seems.

Last time - evolution-addressbook-export was in the global path, and (I believe)
OO.o hard-coded some mystic, prefix-dependant path to it.

Now we've put it in some mystic, prefix dependant path (poetic justice methinks :-)

On my machine it is:
/opt/gnome/libexec/evolution/2.0/evolution-addressbook-export

But on RH machines etc. it'd be /usr/libexec/... I guess.

Okay, thanks.

Marc, could you please confirm this and then assign the issue to Wind?

//development.openoffice.org/releases/OOo_2_0_timetable.html  2/3 down


	canceled
	PCD Gnome Integration - Extend current solution to import all adressbooks (cp)
	evoab03

Has the cancellation of evoab3 anything to do with this issue ?

Not really. evoab3 was about making OOo aware of all address books in evolution,
which should have been independent on making OOo Evo2.0-aware. In the meantime,
it should that you cannot really separate these two, since OOo's way to access
Evo doesn't work anymore with Evo 2.0.

(side note: correcting priority according to
http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#priority).
Since Ximian (in persona Michael Meeks) contributed back their fixes to make
their Ximian Office (not sure whether this is the proper name :) Evo2.0-aware,
we can now try to fix this for the OOo 2.0 branch.

I can't also access by evolution 1.5.94.1 addressbook -> reassign to windly

I finally find out the reason why we can't access Evolution 2.0 address books. 
See http://bugzilla.ximian.com/show_bug.cgi?id=69870.
evolution-addressbook-export --format=csv does not work now.

grabbing

Thankfully, Ximian already has a patch for this. Michael Meeks offered us those
patches, to be found at http://ooo.ximian.com/patches/evo2/.

I'm planning to do a review of them ASAP (Michael, did you by chance find time
to integrate them into a dedicated CWS?), and then all what's left is to build a
CWS ...

accepting

forgot: Wind, thanks for finding this issue @ximian! :)

Created attachment 20213 [details]
patch supplied by mmeeks

Created attachment 20374 [details]
review results

I attached the results of the patch review here, instead of pasting them into
the description.

Michael, there are a few points which definately need to be addressed before
putting this into the final product, plus a number of nits which should not
hinder an integration.

I could assist in resolving some of those, but only after I have this thing
compiling, which leads me to:
- Do I see this right that currently, this compiles only on systems where Evolution
  is installed? This could make it somewhat difficult ...
- Where do the needed Evolution include files / libs come from? Is there some
  configuration option to point my build env to them?

Thanks
Frank

forget to mention that in the review text file, serious issues are marked with a
'*', everything else with '-'

Hi Frank; so - the guy who did much of this work is Jayant:

Jayant - can you work through the problems that Frank has identified, fixing /
responding to the queries one by one ?

Frank - I'm unconvinced by the authentication situation; I suspect there will be
nasty problems here.

The same back-end (evolution) may, or may not require authentication - depending
on a number of factors [ local-file, or remote LDAP, exchange, G/W ], worse the
results returned may depend on whether you are authenticated or not.

Will your higher-level authentication code work with this ?

First a general note why your current solution is bad, then ideas how to solve
it :).

A requirement (by definition) for every UNO API is that unless told otherwise,
no component should at its own authority invoke any user interface. If you call
XFoo.doSomething, and this invokes UI, this is considered a bug.
The past has shown that such behaviour would make the API, and thus OOo as a
whole, not scriptable. If everything you do while using the API has the
potential to block you whole script, the API is rendered useless.
I know that this rule has not been followed in OOo 1.x :), but all known places
vialoting it should have been fixed in the meantime.

In general, if your component needs UI, its client either needs to *explicitily*
allow it, or pass a callback to be used when UI is needed.

For SDBC drivers, the idea is that whoever invokes the driver, must pass the
necessaary (authentication) information (which is done in the info sequence in
XDriver::connect), or pass a callback which the driver can use to obtain this
information.



In OOo, the user who creates the database usually should know whether the
backend needs authentication. There's a "User"/"need password" setting for this
in the database properties dialog (data source administration in 1.x).

Shouldn't this also hold for an EvoAB? If I as a user create a "Evolution
address book database" in OOo, shouldn't I know whether this address book
requires authentication? If so, I should enter this in the database properties.
Then OOo will authenticate before connecting, and pass the authentication
information down to the driver.

If for some reason this does not work - i.e., if a user cannot decide on a
per-database basis whether it requires authentication, but this needs to be
decided dynamically at connection time -, then we need to pass down a callback.
Despite what I said in the review.txt, XCompletedConnection would not be a
solution, as it is lacking some information. What we would need is a method
analogous to XDriver::connect, which additionally gets an XInteractionHandler
passed (the usual interaction handler implementation is able to handle
authentication requests).

Hi, as Martin pointed out on the releases list we are coming
closer to 2.0 Beta.
http://www.openoffice.org/servlets/ReadMsg?list=releases&msgNo=8258
Is your work making progress and would be ready for 2.0
as the target milestone indicates?
Thanks, Stefan

Yes - it is progressing well; we've checked the data into the evoab201 cws - and
we're waiting for Frank's final review / approval etc. Re-assigning to Frank.

Jayant and Michael, thanks for your work on this! I'll care for this CWS ASAP
(which is next week).

Created attachment 22697 [details]
open items

fs->jayant: attached you find a list of open issues with the code, mostly minor
ones, where only 4 are serious enough to block the integration.

I'm going to play with building this thing ....

retarget to 2.0.1

*** Issue 40317 has been marked as a duplicate of this issue. ***

have a look on issue 40317 also

Issue 40317 is not solved in 2.0.1 RC2 as packaged by the Fedora Core 4
update openoffice.org-...-2.0.1-143.2.1.

As already mentioned in that issue, this makes the integration with
evolution pointless, or at least very unusable...

Since issue 40317 has been marked duplicate of the current issue, this
cannot be set as resolved.

Caolan - might be interesting; Frank - any idea why this is marked 'Resolved
Fixed' seemingly without a comment ?

Not really. Probably because there was a wild mix: 2 different drivers, plus
some initial bug in the CSV exporter in Evo2 which affected one of the drivers.

I think this issue here was (finally) used as "implement the new driver", not as
"Evo2-access doesn't work anymore" ....


Which driver is part of Fedora's OOo build - libevoab1 or libavoab2?

From what I see, they are both in there:

/usr/lib/openoffice.org2.0/program$ ls -l libevo*
-rwxr-xr-x  1 root root 282624 Dec  4 18:24 libevoab1.so
-rwxr-xr-x  1 root root 196116 Dec  4 18:24 libevoab2.so

I can understand that the reason for this bug was to implement the
driver, but then my original bug should not have been made duplicate
of this one...  Should I reopen Issue 40317 ?

Yes, you might want to do so.

The Issue you raised has been marked as 'Resolved' and not updated within the
last 1 year+. I am therefore setting this issue to 'Verified' as the first step
towards Closing it. If you feel this is incorrect, please re-open the issue and
add any comments.

Many thanks,
Andrew
 
Cleaning-up and Closing old Issues
~ The Grand Bug Squash, pre v3 ~
http://marketing.openoffice.org/3.0/announcementbeta.html

As per previous posting: Verified -> Closed.
A Closed Issue is a Happy Issue (TM).

Regards,
Andrew