Re: [Evolution-hackers] Evolution calendar backend

2011-01-22 Thread Adam Tauno Williams
On Sat, 2011-01-22 at 10:57 -0600, Kirk Wolff wrote: 
 Hello,
 I've been digging through calendar's webdav backend 

The calendar is CalDAV [it uses REPORT methods]; a descendant of WebDAV.

 code and found that 
 there's special handling of calendar items (components) that have
 the same UID.  Under what circumstances would two calendar items
 have both the same UID and href?  

I suppose this could happen in the case of editing a recurrence [I don't
specifically know how evolution internally handles recurrences;  but I
work on a CalDAV server and ... man, are recurring events in iCal/CalDAV
stupid and a pain].

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Multiple child-addressbooks under an account

2011-01-22 Thread Adam Tauno Williams
On Fri, 2011-01-21 at 19:49 +0100, Onyeibo Oku wrote: 
 On 01/21/2011 06:30 PM, Kirk Wolff wrote:
  Is there a way to add child-addressbooks under an addressbook account
  with evolution's GUI? I don't see any current implementations that have
  a 'tree' of addressbooks under an addressbook plugin type. As I see it,
  there are plugins for setting up an addressbook, but not for displaying
  and organizing them. It seems the presentation (the left-hand column
  list) of addressbooks is fixed. Is there a simple way to add and
  maintain a tree in the list of addressbooks?
 I don't see any special benefit for this feature.  

The use case seems *obvious* to be; especially for WebDAV address books
since WebDAV supports hierarchical collections [although
CalDAV/CardDAV/GroupDAV all place restrictions on how child collections
can be structured].

If you have multiple server-side collections of contacts you currently
have to define multiple addressbooks rather than just one that can
expand to list the collections - even supporting descending a single
level of collections would be *very* useful.

 I will campaign 
 rather for child-tasks (sub-tasks) where completion of each child task 
 sums up the percentage progress for the parent/container task

This really seems like a server-side issue to me.  The issue really is
there is no way standard way to specify a hierarchy of tasks in either
UI or in the representation [VTODO] so I think that would be a
special/custom plugin.  But if you right one I'll support it in my
server because it would be very useful.  In the same manner there is no
way to deal with delegation.  


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Evolution calendar backend

2011-01-22 Thread Kirk Wolff
 From: Adam Tauno Williams awill...@opengroupware.us
 To: evolution-hackers@gnome.org
 Subject: Re: [Evolution-hackers] Evolution calendar backend
 Date: Sat, 22 Jan 2011 14:59:31 -0500 (01/22/2011 01:59:31 PM)
 
 RFC4891

 4.1.  Calendar Object Resources
 

...

The UID property value of the calendar components contained
in a
calendar object resource MUST be unique in the scope of the
calendar
collection in which they are stored.
 
Calendar components in a calendar collection that have
different UID
property values MUST be stored in separate calendar object
resources.
 
Calendar components with the same UID property value, in a
given
calendar collection, MUST be contained in the same calendar
object
resource.  



 
The VEVENT component with the UID value 1...@example.com
would be
stored in its own calendar object resource.  The two VEVENT
components with the UID value 2...@example.com, which
represent a
recurring event where one recurrence instance has been
overridden,
would be stored in the same calendar object resource.


I take it from the above reply that the code handling items with the
same UID are for handling recurrences.  I'll look closer at the caldav
spec and see if the sync code makes more sense.


signature.asc
Description: This is a digitally signed message part
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers