Re: [Evolution-hackers] Evolution calendar backend
> From: Adam Tauno Williams > 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
Re: [Evolution-hackers] Evolution calendar backend
On Sat, 2011-01-22 at 14:18 -0500, Adam Tauno Williams wrote: > 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]. RFC4791 4.1. Calendar Object Resources Calendar object resources contained in calendar collections MUST NOT contain more than one type of calendar component (e.g., VEVENT, VTODO, VJOURNAL, VFREEBUSY, etc.) with the exception of VTIMEZONE components, which MUST be specified for each unique TZID parameter value specified in the iCalendar object. For instance, a calendar object resource can contain one VEVENT component and one VTIMEZONE component, but it cannot contain one VEVENT component and one VTODO component. Instead, the VEVENT and VTODO components would have to be stored in separate calendar object resources in the same collection. Calendar object resources contained in calendar collections MUST NOT specify the iCalendar METHOD property. 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. This ensures that all components in a recurrence "set" are contained in the same calendar object resource. It is possible for a calendar object resource to just contain components that represent "overridden" instances (ones that modify the behavior of a regular instance, and thus include a RECURRENCE-ID property) without also including the "master" recurring component (the one that defines the recurrence "set" and does not contain any RECURRENCE-ID property). For example, given the following iCalendar object: BEGIN:VCALENDAR PRODID:-//Example Corp.//CalDAV Client//EN VERSION:2.0 BEGIN:VEVENT UID:1...@example.com SUMMARY:One-off Meeting DTSTAMP:20041210T183904Z DTSTART:20041207T12Z DTEND:20041207T13Z END:VEVENT BEGIN:VEVENT UID:2...@example.com SUMMARY:Weekly Meeting DTSTAMP:20041210T183838Z DTSTART:20041206T12Z DTEND:20041206T13Z RRULE:FREQ=WEEKLY END:VEVENT BEGIN:VEVENT UID:2...@example.com SUMMARY:Weekly Meeting RECURRENCE-ID:20041213T12Z DTSTAMP:20041210T183838Z DTSTART:20041213T13Z DTEND:20041213T14Z END:VEVENT END:VCALENDAR 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. ___ 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
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
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] Rebasing gtk3 branches
On Wed, 2011-01-12 at 20:53 -0500, Matthew Barnes wrote:
> The gtk3 branches are rebased now. Delete your local copy.
Would anyone mind if I do another round of gtk3 rebases?
Benjamin Otte fixed most of the gnome-canvas issues, and I've been
rebasing and reorganizing commits on my gtk3 branches almost daily.
What I'm running right now are my private gtk3 branches rebased against
today's master branches and linked against stock platform libraries from
Fedora 15 ("Rawhide") and it's quite usable. A few minor glitches left
but canvas widgets now draw and scroll correctly, and I'm seeing a few
but not an enormous number of runtime warnings on the terminal.
I'd like to rebase again so we're all on the same page. I'll plan to do
it Monday unless someone objects.
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Evolution calendar backend
Hello, I've been digging through calendar's webdav backend 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? >Kirk 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
Re: [Evolution-hackers] evolution-hackers Digest, Vol 66, Issue 10
I am not referring to tasks, but to addressbooks. -- Kirk Wolff Wolff Electronic Design (651) 224-0412 x200 Fax: (651) 925-0412 k...@wolffelectronicdesign.com On Sat, 2011-01-22 at 12:00 +, evolution-hackers-requ...@gnome.org wrote: > Send evolution-hackers mailing list submissions to > evolution-hackers@gnome.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.gnome.org/mailman/listinfo/evolution-hackers > or, via email, send a message with subject or body 'help' to > evolution-hackers-requ...@gnome.org > > You can reach the person managing the list at > evolution-hackers-ow...@gnome.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of evolution-hackers digest..." > Today's Topics: > >1. Multiple child-addressbooks under an account (Kirk Wolff) >2. Re: Multiple child-addressbooks under an account (Onyeibo Oku) > > email message attachment > > > Forwarded Message > > From: Kirk Wolff > > To: evolution-hackers@gnome.org > > Subject: [Evolution-hackers] Multiple child-addressbooks under an > > account > > Date: Fri, 21 Jan 2011 11:30:29 -0600 > > > > 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? > > > > >Kirk > > > > > > > > > > > > > > email message attachment > > > Forwarded Message > > From: Onyeibo Oku > > Reply-to: twoho...@gmail.com > > To: evolution-hackers@gnome.org > > Subject: Re: [Evolution-hackers] Multiple child-addressbooks under > > an account > > Date: Fri, 21 Jan 2011 19:49:53 +0100 > > > > > > 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? > > > > > >>Kirk > > > > I don't see any special benefit for this feature. 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 > > > > > > ___ > evolution-hackers mailing list > evolution-hackers@gnome.org > http://mail.gnome.org/mailman/listinfo/evolution-hackers 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
