[OGo-Evolution] OGo - evolution connector uploaded in CVS

[Helge Hess]

On Aug 17, 2006, at 16:55, Robert de Geus wrote:
> I have read the groupdav specs, in principle this is what we want to
> adhere to. It would be helpfull if we have an overview of the
> discrepancies between opengroupware and groupdav.

The question can be mostly narrowed down to:
a) what parts of iCalendar are supported by OGo
    - eg custom attributes X-
    - alarms
    - recurrences
    - attachments
b) what parts of vCard are supported by OGo

 From the WebDAV part I can see two immediate issues:
a) missing: vTODO PUT
b) object creation is (incorrectly) bound to a single URL

And more advanced stuff would need to go above WebDAV, eg for access  
control.

> I know you are in the
> original group who made the draft, so my guess is that opengroupware
> stays close.

The motivation was not to write an OGo specific protocol but one  
which could find acceptance by a large group of server and client  
vendors to avoid duplicate efforts.
So the draft isn't tied a lot to OGo.

> But there are difficulties, for example
> zidestore implements a directory structure, evolution does not  
> allow for
> subdirectories of folders.

Yes, thats a tricky one (the flattening is copied from Outlook 2003).  
In fact Evo did support a directory structure <2.0. And I think the  
Evolution Connector for Exchange still has that, maybe we can reuse it?

> Ad 3: we only implement events tasks and contacts,
> missing: journals and mails

OGo doesn't support the two anyway. Maybe we could map project/apt  
notes to journals, don't know.
And mails are better handled by IMAP4 thought it would be cool if  
some "wizard" would setup a full OGo account, that is, GroupDAV  
things (events/tasks/contact) and IMAP4 stuff.

> Ad 3.1 I dont understand the FREEBUSY implemntation, how does this  
> apply
> in zidestore?

Not sure what you mean, possibly this one:
---snip---
Since collections on the server can contain private items of other
    users, the user may only have access to the start and end time of an
    event. Instead of creating a special permission for this case, the
    server should deliver a valid iCalendar VFREEBUSY file containing
    exactly one busy record.
---snap---

Its not done this way by ZideStore. Which can be considered a bug.


> Ad 3.1.1. Recurring items can be created in a new calendar item  
> (webui),
> you can change each recurring item individually, the only operation
> which applies on the recurring list, is the delete all. The delete all
> applies also to the changed items. Also when changing one of the items
> in evolution, the zidestore server keeps the list so is still able to
> delete the whole list. Do we also allow this in evolution, or can this
> even be done?

This one is very tricky. The issue is that iCalendar(/Evo) uses  
'calculated' recurrences while OGo always "flattens" recurrences on  
creation.

I think there is little the connector can do about it, its ZideStore  
side stuff. If Evo PUTs a recurring event, ZideStore somehow needs to  
deal with it.
The important thing is that the connector resyncs the collection  
after a PUT. So that if the server can choose to create multiple  
events from one (possibly connected using iCal exceptions, though  
ZideStore doesn't do this [yet]).


> Ad 3.1.2. Alarms, at this moment in the current connector  
> implementation
> we get all alarms of all calendar items stored on the zidestore  
> server.
> If I look at the specification, it says no alarm, if I think what I
> would like to have is getting the alarm for my own calendar items
> (centrally stored), but not of the ones created by others.

OGo WebUI only stores one alarm for all. OGo ZideStore does the same  
(in a different DB field! So WebUI alarms and Evo alarms are  
separate). This could be changed to be per-attendee, but it doesn't  
work this way right now.

I'm not entirely sure but it might be best to keep alarms at the  
client and NOT push/retrieve them to the server at all.

> Ad 3.2. Tasks some things work, but we have not touched tasks yet. We
> have not observed users using tasks, so it is not high on our wish  
> list.
> This will be implemented in a basic way as it looks now, just to  
> make it
> working.

Si.

> Ad 3.2.1. Recurring Tasks, even more exotic, I don't see this
> implemented.

Its not supported by OGo anyways.

> Ad 3.2.2. Connected Tasks in the groupware server tasks are  
> connected in
> projects, evolution has no way to display projects, so this probably
> will not be implemented

It would be quite awesome if OGo projects could be added to Evo,  
possibly using some Evo UI plugin mechanism.
Though this would be very much OGo specific.

> Ad 3.3. Contacts high on the priority list, should support proper
> caching as described by the groupdav specs, categories should be
> displayed and usable.

Yup.

> Does zidestore provide a way to see all defined
> categories?

No. Are the categories predefined inside Evolution are not good enough?
I think you can fetch the categories using XML-RPC, though it would  
probably be easy for me to add that to ZideStore too.
=> not GroupDAV in any case

> Does evolution have a way to display them and store them on
> the server?

Sure, categories retrieval/storage should be fully supported. I think  
I already wrote that in another way.

> Ad 3.4. Journals What are journals????

You don't use Outlook, eh? ;-) Journals are "activity logs". Somewhat  
like a blog or notes. Timed notes if you want.


> Ad 4. Handling of UIDs, this is important for meetinging?

iCalendar (like Outlook) uses email addresses as UIDs. Its important  
that all attendees have (unique) email addresses set for scheduling  
to work.
I'm not sure whether we add additional IDs to <attendee> iCal tags.

> At this moment the connector does not save the meeting names.

Not sure what you mean by that.

> One could think of displaying all employees for a meeting, or,  
> allow for arbitrary names to be stored.

This should work just fine - if emails are properly setup.

> What to do if users enter email addresses which dont exist in
> zidestore?

ZideStore autocreates a private contact.

> In most companies, you would like to schedule with employees.

Yes.

Greets,
   Helge
-- 
Helge Hess
http://docs.opengroupware.org/Members/helge/