[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opengroupware-evolution
Subject:    Re: [OGo-Evolution] ZideStore functionality
From:       Helge Hess <helge.hess () opengroupware ! org>
Date:       2003-07-25 17:18:37
[Download RAW message or body]

On Freitag, 25. Juli 2003, at 16:17 Uhr, Dan Winship wrote:
> Here's what I can think of for "things the Exchange Connector has to do
> to talk to Exchange that you really don't want an OGo Connector to have
> to deal with":

;-)

> Contacts:
>       * Exchange doesn't do vCard natively, so we have to split up
>         vCards from evolution into properties. (Although the properties
>         at least have sane names for the most part:
>         "urn:schemas:contacts:givenName" for instance.)

So the Evolution API expects to get vCards from the backend? OK, we  
already have a way to get a vCard from ZideStore, would probably need  
some work to make it complete.

You can get a vCard from an OGo object by adding ".vcf" to the ID, eg:
   GET /zidestore/so/helge/Contacts/29382.vcf

>       * Exchange doesn't let us PROPPATCH the "Notes" field of the
>         contact, so we have to do both a PROPPATCH and a PUT when doing
>         some creates/updates.

Yes, I know :-( This is something which doesn't work yet even with the  
ExConnector on creation, since we "rewrite" the URL you generate during  
a save (to a database sequence key). Not that difficult to implement  
though.

>       * There are some places where we break up the data incorrectly.
>         (qv bug 40772 in bugzilla.ximian.com)

I think the ZideStore Evo address renderer already tries to work around  
some issues here. The whole idea of this free form address field is  
somewhat, well, xxxx.

> I think ideally, ZideStore would just let the OGo Connector GET and PUT
> vCards directly.

Sounds good. GET already works to some degree and PUT is probably easy  
to add (we could do this in 1-2 days).

> Calendar/Tasks:
>       * The calendar code is for the most part not all that awful,  
> since
>         Exchange does iCalendar. Exchange returns funky iCalendar in
>         some cases though, which I assume ZideStore must emulate, which
>         means that the OGo connector will have to de-funk it. (Eg,
>         Exchange does not represent all-day events the same way
>         Evolution does.)

OGo doesn't really support "all day" events, we rather make them a  
00:00-23:59 appointment in the timezone of the user, which seems to  
work rather well and usually is, what people mean with "all day" in a  
timezone aware setting.
But I'm not 100% sure on the current state of that.

BTW: the same goes for repetitive appointments, which are handled quite  
different in OGo.

>       * The free/busy interface could be nicer. (Returning VFREEBUSY
>         data rather than XML junk.)

This is already supported by ZideStore and eg used by Outlook for  
freebusy (pretty weird, we need to use the propritary XML format for  
Evolution and can use the standard one for Outlook ;-).

>       * The tasks code is nasty, because Exchange doesn't support
>         iCalendar tasks, and unlike contacts, the properties don't have
>         sane names. There is also a greater mismatch between
>         Outlook/Exchange formats and Evolution/iCalendar formats here
>         than in other places. (Eg, the possible status values for a  
> task
>         don't match up.) It also has the same problem as contacts that
>         sometimes you need to do both a PROPPATCH and a PUT.

Yes. All the weird codes are mapped to "sane" names in the WebDAV layer  
of SOPE. We obviously should use "real" names with a native connector.
Evo Connector uses the "fake" iCalendar WebDAV property of Exchange  
which I found rather weird (it was probably easier than to decode the  
individual MAPI attributes).

> Again, assuming that OGo works with iCalendar internally, it would be
> easiest for an OGo connector if it could also just deal with iCalendar
> too.

No, (as with vCard) OGo doesn't work with iCalendar internally, but the  
ZideStore server can deliver OGo data as iCalendar.

Hm. Actually I'm not sure whether we should really use iCalendar for  
access/changes. Why not just use WebDAV for that? Eg WebDAV has the  
advantage that we only need to PROPPATCH the attributes which actually  
changed. It has quite some overhead in OGo to assemble/disassemble the  
proper database table records (OGo doesn't use a structured and  
normalized table structure).
Maybe it's a good idea to use iCal-over-WebDAV (use the iCalendar  
property names as WebDAV properties)?

Unsure about that, probably depends on how exactly the Evolution  
backend API is and what's easiest for the plugin writer.

> Other:
>       * Exchange doesn't provide any way for you to fetch the whole
>         folder tree at once. (Well, it does, but it's insanely slow if
>         you have lots of folders.) It would simplify the OGo Connector
>         if ZideStore did.

Hm. Since OGo folders are a "virtual" construct (I guess pretty much  
like Evo vFolders, they map queries to a hierarchy), they can - in  
theory - nest dynamically and very deep.
But I'm not sure whether that has a practical application. We could of  
course provide an operation (either XML-RPC or REST) which returns at  
the least as much of the tree as can be calculated.

>       * I assume ZideStore implements httpu change notifications like
>         Exchange does? (qv
>          
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wss/ 
> wss/_webdav_notify.asp).

Yes, but this isn't completed yet (the database polling is not  
implemented). But everything is prepared in SOPE for HTTPU, would need  
a week or two and should be implemented in a separate daemon.

> Architecturally, this is a problem because sometimes the server can't  
> initiate packets back to the client (eg, if the client is behind a  
> NAT). Exchange's specific implementation is annoying because when you  
> get a "delete" or "move" notification, there's no way to find out  
> *what* was deleted or moved other than by fetching the list of UIDs  
> from the server again, which is slow.

In Outlook we use polling for that. Every n-minutes the ZideLook plugin  
issues a "getIDsAndVersions" query (a GET) on each folder - the returns  
the generation and primary key of each object contained in a folder and  
is a rather cheap database operation (since both attributes are  
contained in the same database table).

Do you have some other suggestions on a good implementation of that?  
Obviously a server triggered action scales better (at least in theory).

> The preferences dialog is expandable. You just need to implement the
> IDL:GNOME/Evolution/ConfigControl:1.0 interface. (The shell queries
> bonobo-activation for all components that implement that and activates
> them all when it creates the preferences dialog.)

Excellent. (in case anyone is interested, the OGo WebUI is completely  
driven by such an activation framework).

> There's no way to extend the task/contact/meeting dialogs currently,
> though such a possibility isn't out of the question.

This would be really required for a "rocking" OGo frontend, since most  
advantages of OGo are in the structured backend, associating projects  
with jobs or appointments, etc.

regards,
   Helge
-- 
OpenGroupware.org	- http://www.opengroupware.org/


[prev in list] [next in list] [prev in thread] [next in thread]