[Bitpim-devel] Evolution address book interface

[Peter Pletcher]

I've implemented an interface to the Evolution EBook
API to query the 'default address book'. I needed
this for importing from Evolution 1.4 as I don't even
have an addressbook.db file.

This was built for Evolution 1.4.6 - I have not tested
it with 1.2.x or the (development) 1.5 series as I
don't have access to such a system.

Untar the attached evolution_utils.tar.gz file into
native/evolution and run 'make' to build it. You'll
need GNOME and Evolution development libraries.

Here's a patch for evolution.py that attempts to use
this extension. If it fails we fall back to pawing
around the filesystem:

Index: evolution.py
===================================================================
RCS file:
/cvsroot/bitpim/bitpim/native/evolution/evolution.py,v
retrieving revision 1.4
diff -u -r1.4 evolution.py
--- evolution.py 29 Jun 2004 00:13:33 -0000
1.4
+++ evolution.py 2 Jul 2004 22:53:42 -0000
@@ -9,9 +9,11 @@

"Be at one with Evolution"

-# Evolution mostly sucks when compared to Outlook.
The UI and functionality
-# for the address book is a literal copy. There is
no API as such and we
-# just have to delve around the filesystem
+# Use the EBook API to query the default address book
for vcards.
+# This is built for Evolution 1.4 - for previous (or
later) versions we may
+# just have to fall back to the addressbook.db file.
+
+# To delve around the filesystem:

# root directory is ~/evolution
# folders are any directory containing a file named
folder-metadata.xml
@@ -54,6 +56,14 @@
"""Returns the contacts as a list of string
vcards

Note that the Windows EOL convention is used"""
+
+ try:
+ import evolution_utils
+ res = evolution_utils.query_default_book(
'(contains "x-evolution-any-field" "")' )
+ return res
+ except:
+ pass
+
dir=os.path.expanduser(folder)
p=os.path.join(dir, "addressbook.db")
if not os.path.isfile(p):

[Roger Binns]

Post by Peter Pletcher
I've implemented an interface to the Evolution EBook
API to query the 'default address book'.

The code needs attributions and license information.
There are no copyrights at all on it!

The extension module looks nice, but needs some changes.
In particular it hard codes the Python version (2.2)
which it shouldn't do, and BitPim uses 2.3 anyway.

Post by Peter Pletcher
I needed
this for importing from Evolution 1.4 as I don't even
have an addressbook.db file.

How is it actually storing the addressbook then? Is
it being retrieved over LDAP or something similar?

Post by Peter Pletcher
This was built for Evolution 1.4.6 - I have not tested
it with 1.2.x or the (development) 1.5 series as I
don't have access to such a system.

Unfortunately the code is very unfriendly for binary
distribution due to the Evolution dependencies,
and as an extension module they get linked into
the Python process which makes for an even more
precarious environment.

My preference would be for a binary that can be
run with two different command line flags. The
first is just a check to see if it would work.
That would verify shared library linking as well
as some sort of correspondence to the version
of Evolution on the system. The expectation
would be for a zero error code on success,
and something different for failure.

If it succeeds I would then add a pseudo folder
(eg "Import via ebook") before the other folders
shown.

The second flag would just dump all the vcards
to stdout in UTF-8.

This way BitPim can offer both mechanisms. We
could also have a number of binaries with different
linkages and Evolution versions or whatever the
dependencies are.

Post by Peter Pletcher
Untar the attached evolution_utils.tar.gz file into
native/evolution and run 'make' to build it. You'll
need GNOME and Evolution development libraries.

It looks like a standard distutils module which is
how I prefer to work with things. However due to
the hairy dependencies and possibilities for all
sorts of runtime issues I far prefer the external
binary mechanism listed above. That way we can easily
test it outside of BitPim, as well as support multiple
versions of Evolution/Gnome with multiple binaries.

The good news is that if you use the Ximian binary
installer you can get Evo 1.4 as well as the developer
libraries for the RH9 build environment.

Roger

[Peter Pletcher]

Roger Binns wrote:

[snip]

Post by Roger Binns
The extension module looks nice, but needs some changes.
In particular it hard codes the Python version (2.2)
which it shouldn't do, and BitPim uses 2.3 anyway.

We all do that sometimes :) e.g. see bitpim/native/usb/build.sh

[snip]

Post by Roger Binns
My preference would be for a binary that can be
run with two different command line flags.

Well, I was envisioning something able to use the flexibility of the
EBook query API, but I understand your concerns about distribution
issues. That can be a nightmare.
If you want a standalone 'dump everything' binary you can just use the
one that comes with Evolution.

Something like (for evolution 1.4.x):

===================================================================
RCS file: /cvsroot/bitpim/bitpim/native/evolution/evolution.py,v
retrieving revision 1.4
diff -u -r1.4 evolution.py
--- evolution.py 29 Jun 2004 00:13:33 -0000 1.4
+++ evolution.py 6 Jul 2004 19:26:04 -0000
@@ -9,9 +9,10 @@

"Be at one with Evolution"

-# Evolution mostly sucks when compared to Outlook. The UI and
functionality
-# for the address book is a literal copy. There is no API as such and
we
-# just have to delve around the filesystem
+# Use the evolution-addressbook-export utility to query the default
address book
+# for vcards. If this doesn't work then fall back to the
addressbook.db file.
+
+# To delve around the filesystem:

# root directory is ~/evolution
# folders are any directory containing a file named
folder-metadata.xml
@@ -35,6 +36,7 @@

import sys
import os
+import re

if sys.platform!="linux2":
raise ImportError()
@@ -54,6 +56,34 @@
"""Returns the contacts as a list of string vcards

Note that the Windows EOL convention is used"""
+
+ try:
+ evo_version = os.popen("evolution-addressbook-export
--version")
+ evo_version_result = evo_version.read()
+ evo_version_status = evo_version.close()
+ if evo_version_status is not None:
+ raise IOError
+ p = re.compile('(?P<maj>\d+)\.(?P<min>\d+)')
+ m = p.search(evo_version_result)
+ if m is None:
+ raise ValueError
+ if m.group('maj') == '1' and m.group('min') == '4':
+ evo_export = os.popen("evolution-addressbook-export")
+ evo_cards = evo_export.read()
+ evo_export_status = evo_export.close()
+ if evo_export_status is not None:
+ raise IOError
+ p = re.compile('(?<!\r)\n')
+ cardlist = p.split(evo_cards)
+ while len(cardlist) and cardlist[-1] == '':
+ cardlist.pop()
+ return cardlist
+ else:
+ raise ValueError
+ except:
+ pass
+
+
dir=os.path.expanduser(folder)
p=os.path.join(dir, "addressbook.db")
if not os.path.isfile(p):
===================================================================
It looks (from source code) like the evolution-addressbook-export
utility for Evolution 1.2.x works a bit differently. It writes to a
/tmp file and prints the filename so you'd have to open that file
instead. Again, I don't have such a system on which to test
unfortunately.
Any volunteers on this?

[snip]

Post by Roger Binns
The good news is that if you use the Ximian binary
installer you can get Evo 1.4 as well as the developer
libraries for the RH9 build environment.

There are also RH9 binary RPMs for evolution and evolution-devel
available from the usual sources.

[Roger Binns]

Post by Peter Pletcher
[snip]

Post by Roger Binns
The extension module looks nice, but needs some changes.
In particular it hard codes the Python version (2.2)
which it shouldn't do, and BitPim uses 2.3 anyway.

We all do that sometimes :) e.g. see bitpim/native/usb/build.sh

Yes, but BitPim is defined to only work with Python 2.3 on Linux
so that is correct :-)

Post by Peter Pletcher
If you want a standalone 'dump everything' binary you can just use the
one that comes with Evolution.

The only problem is that it doesn't work. For example the
evolution-addressbook-export on Redhat 9 just hangs forever.

BTW I won't do it the way you are supplying the patches. Instead
a first pseudo folder should be listed and when selected then
the ebook code/evolution-addressbook-export is called and data
from that returned. If you supply working code today, I'll
put it into the build.

The code would be something like this:

- rename getfolders to getfilefolders
- create getfolders
- call evolution-addressbook-export --version and if
happy include a special folder (eg "<Evolution Contacts>")
- append results of getfilefolders
- modify getcontacts to look for special folder name and
return results of evolution-addressbook-export if supplied
else use existing code
- ensure the right thing happens for folders vs folderids. The
concept is taken from Outlook where a folderid is actually
a hex string of a guid for the folder and stays the same
even if the folder is renamed etc, and the folder object
is what functions like getcontacts() expect. The evolution
code mostly treats folders and folderids as the same thing
but shouldn't

Post by Peter Pletcher
It looks (from source code) like the evolution-addressbook-export
utility for Evolution 1.2.x works a bit differently. It writes to a
/tmp file and prints the filename so you'd have to open that file
instead. Again, I don't have such a system on which to test
unfortunately.
Any volunteers on this?

It just hangs, even if --output-file argument is supplied.

--version prints:

Gnome evolution-addressbook-clean 0.0

I would suggest making the check on the output of --version
look for something starting with "Gnome evolution 1.4"
since we know that will work.

Post by Peter Pletcher
[snip]

Post by Roger Binns
The good news is that if you use the Ximian binary
installer you can get Evo 1.4 as well as the developer
libraries for the RH9 build environment.

There are also RH9 binary RPMs for evolution and evolution-devel
available from the usual sources.

However they are not part of the standard updates for RH9
and we should still work with a RH9 baseline system.

Roger