GNOME.org
 

Re: [Evolution] Evolution webdav sending malformed URI

On Mon, 2010-05-10 at 20:18 -0400, John A. Sullivan III wrote:

On Mon, 2010-05-10 at 06:18 -0400, John A. Sullivan III wrote:

On Mon, 2010-05-10 at 10:16 +0200, Milan Crha wrote:

On Sat, 2010-05-08 at 19:20 -0400, John A. Sullivan III wrote:

Can anyone point me in the right direction for both where the URI is
created and general hacking on Evolution?


  Hi,
there is no such thing, Evolution is just huge, and divided in multiple
products. There are some architecture texts on
http://live.gnome.org/Evolution
, but they are probably slightly outdated with respect of 2.30/2.31,
thought the ideas are still the same.

For WebDAV, see evolution-data-server/addressbook/backends/webdav, there
is all you need, except of UI part, which is inside evolution sources,
as a plugin.
  Bye,

<snip>
I've been recording my (sad) progress in
https://bugzilla.gnome.org/show_bug.cgi?id=604650

It looks like the webdav creation of the URI is correct although I
really do not know what I am doing.  Although the process is different
than the correctly functioning caldev process, the end result looks the
same and, substituting the caldev code for the webdav code does not fix
the problem.

It looks like either a SOUP problem or, perhaps more likely, the way
webdav is storing the URI.  I did notice that the caldev URIs are stored
as user%40domain server domain/dav/user domain . . .
while webdav URIs are user domain@server.domain/dav/user domain . . .

Perhaps SOUP is misinterpreting that.  However, so far, if I change the
syntax in the %gconf.xml, I fail authentication.  Any ideas as I'm
really beating my head bloody on this one.  Thanks - John

The patch you provided seems to have worked but has revealed the next
couple of issues.  It URI seems properly formed.  I have removed the
strange /etc/hosts file entry.  I can retrieve contacts without it.

However, now I must ensure I do NOT add a terminating "/" to the URI or
it fails.  I Cannot fully verify the path via packet trace as the
traffic seems to insist on using SSL.  I've set all the sources to http
and %gconf.xml so use_ssl=0 and I've restarted evolution-data-server
several times.  However, packet traces all seem to be https.  We are not
enforcing redirection to https within Zimbra (we disabled it for this
testing).  The messages inside Zimbra seem to indicate a properly formed
URI.

The biggest new problem besides the 75 second delay when creating new
contacts referenced in a separate thread is that new contact creation is
not working.  The Evolution dialog returns successfully.  The Zimbra
logs say the contact is created.  If I search for it in Evolution, I can
find it.  However, it is not displayed in Evolution; it is not displayed
in Zimbra and a search in Zimbra (using the web interface) does not find
it.

I've been able to gather a lot more information about this issue but I
do not know if it is a Zimbra or an Evolution issue.  The newly created
contacts are visible in Evolution but not in ZWC (Zimbra Web Client).
Here is what I posted to the Zimbra forum:

SLOWLY getting closer to resolution. We can now see the newly created
contacts in Evolution but they do NOT appear in the Zimbra Web Client.
We do see them in the database. There are a few differences. The
metadata reflects that it was created via vcard. Most noticeably, the
type is different. All of our other contacts including VCF cards
imported from emails in ZWC are type 6. The ones created by Evolution
are type 8.

What is the difference between a type 6 and a type 8?

I tried changing the entry manually in mysql but then ZWC generated a
java error while accessing the Address Book.

There may be other differences but that's the one which jumps out. I
also noticed that none of the type 8 contacts have synchronized with our
Blackberries (running NotifySync with which we are very happy). Here is
a comparison of a database entry from a vcard imported via ZWC and three
other contacts - two created directly in Evolution and the last created
in Evolution by importing an attached VCF file:

| 5 | 95020 | 6 | NULL | 7 | 95020 | 95020 | 1273564396 [1273564396] | 0
| NULL | NULL | NULL | 0 | 0 | Oskar Andreasson | NULL | NULL |
d3:fldd5:email21:someone gmail com6:fileAs1:29:fir
stName5:Oskar8:fullName16:Oskar
Andreasson8:lastName10:Andreasson11:vcardXProps268 
:{"X-EVOLUTION-MANAGER":"","X-MOZILLA-HTML":"FALSE","X-EVOLUTION-SPOUSE":"","X-EVOLUTION-VIDEO-URL":"","X-EVOLUTION-LAST-USE":"2004-01-14","X-EVOLUTION-USE-SCORE":"2.441834","X-EVOLUTION-FILE-AS":"Andreasson,
 Oskar","X-EVOLUTION-ASSISTANT":"","X-EVOLUTION-BLOG-URL":""}e1:vi10ee | 538490 | 1273564396 [1273564396] | 
538490 |
<snip>
mysql> select * from mail_item where type=8;
<snip>
| mailbox_id | id | type | parent_id | folder_id | index_id | imap_id |
date | size | volume_id | blob_digest | unread | flags | tags | sender |
subject | name | metadata | mod_metadata | change_date | mod_content |
<snip>
| 5 | 95015 | 8 | NULL | 32959 | 95015 | 95016 | 1273562162 [1273562162]
| 419 | 1 | +ochiEApLrmaTzyBTLUKo9VvAEk= | NULL | 0 | 0 | NULL |
5514ED0A-6E3B5032-56DCD56A.vcf | 5514ED0A-6E3B5032-56DCD56A.vcf |
d2:cr22:me mycompany com2:ct14:text/directory1:f145:BEGIN:VCARD
VERSION:3.0
TEL;X-EVOLUTION-UI-SLOT=1;TYPE=WORK,VOICE:+44 9867898757 [9867898757]
EMAIL;X-EVOLUTION-UI-SLOT=1;TYPE=WORK:crutch mycompany net ...2:ua18:Evolution/2.28.3.11:vi10ee | 538466 | 
1273562434 [1273562434] | 538454 |

| 5 | 95017 | 8 | NULL | 7 | 95017 | 0 | 1273563955 [1273563955] | 433 |
1 | n0G0dHqPyAtC2CSjvcsUFC1i2kE= | NULL | 0 | 0 | NULL |
67EEC11E-50F1AEF2-40E65C16.vcf | 67EEC11E-50F1AEF2-40E65C16.vcf |
d2:cr22:me mycompany com2:ct14:text/directory1:f147:BEGIN:VCARD
VERSION:3.0
TEL;X-EVOLUTION-UI-SLOT=1;TYPE=WORK,VOICE:+1 (207) 222-3456 [(207)
222-3456]
EMAIL;X-EVOLUTION-UI-SLOT=1;TYPE=WORK:noone mycompany net ...2:ua18:Evolution/2.28.3.11:vi10ee | 538483 | 
1273563955 [1273563955] | 538483 |

| 5 | 95021 | 8 | NULL | 7 | 95021 | 0 | 1273564514 [1273564514] | 149 |
1 | HEMk6nrh31lFMzTEwStZ8q1yfVk= | NULL | 0 | 0 | NULL |
507BACE6-404DD0AC-0A1E3C7F.vcf | 507BACE6-404DD0AC-0A1E3C7F.vcf |
d2:cr22:me mycompany com2:ct14:text/directory1:f149:BEGIN:VCARD
VERSION:3.0
FN:Michael Alexeev
N:Alexeev;Michael;;;
X-EVOLUTION-FILE-AS:Alexeev\, Michael
EMAIL:him gmail com
END:VCARD2:ua18:Evolution/2.28.3.11:vi10ee | 538510 | 1273564514
[1273564514] | 538510 |


A little more digging turned up this article:
Ajcody-Mysql-Topics - Zimbra :: Wiki
With this table:
/** Item is a standard { link Folder}. */
public static final byte TYPE_FOLDER = 1;
/** Item is a saved search { link SearchFolder}. */
public static final byte TYPE_SEARCHFOLDER = 2;
/** Item is a user-created { link Tag}. */
public static final byte TYPE_TAG = 3;
/** Item is a real, persisted { link Conversation}. */
public static final byte TYPE_CONVERSATION = 4;
/** Item is a mail { link Message}. */
public static final byte TYPE_MESSAGE = 5;
/** Item is a { link Contact}. */
public static final byte TYPE_CONTACT = 6;
// /** Item is a { link InviteMessage} with a <tt>text/calendar</tt>
MIME part. */
// public static final byte TYPE_INVITE = 7; // SKIP 7 FOR NOW!
/** Item is a bare { link Document}. */
public static final byte TYPE_DOCUMENT = 8;
/** Item is a { link Note}. */
public static final byte TYPE_NOTE = 9;
/** Item is a memory-only system { link Flag}. */
public static final byte TYPE_FLAG = 10;
/** Item is a calendar { link Appointment}. */
public static final byte TYPE_APPOINTMENT = 11;
/** Item is a memory-only, 1-message { link VirtualConversation}. */
public static final byte TYPE_VIRTUAL_CONVERSATION = 12;
/** Item is a { link Mountpoint} pointing to a { link Folder},
* possibly in another user's { link Mailbox}. */
public static final byte TYPE_MOUNTPOINT = 13;
/** Item is a { link WikiItem} */
public static final byte TYPE_WIKI = 14;
/** Item is a { link Task} */
public static final byte TYPE_TASK = 15;
/** Item is a { link Chat} */
public static final byte TYPE_CHAT = 16;

So it looks like Zimbra is interpreting the vcf as a document rather
than a contact. How do we fix that?

I noticed in REST documentation that one can specify:
dav/user domain/FolderName?fmt=vcf to tell the parser that the data is
to be interpreted as a vcard. However, we cannot do that in Evolution
because it appends the card to the URI and we wind up with an invalid
URI such as:

dav/user domain/FolderName?fmt=vcf/somecard.vcf

I would hope that Zimbra would recognize the data is in vcf format
because of the extension. Evolution is sending:
dav/user domain/FolderName/somecard.vcf

Any ideas? Thanks - John
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]