Re: [Evolution-hackers] UID in vCard
On Tue, 2011-11-15 at 08:41 +0100, Milan Crha wrote: On Mon, 2011-11-14 at 21:06 +0100, Patrick Ohly wrote: What about a CardDAV server? It has server-supplied IDs (the path to the resource) and a UID as part of the vCard stored there? How is that handled at the moment? Hi, there is no exact support for CardDAV as such, the closest is the WebDAV backend, and it generates its own UID too, and it also can download just added contact from the server. It use eTag value as a revision value. hi Milan, The WebDAV backend for the addressbook works fine against a CardDAV server. Unlike CalDAV where there are substantial differences between WebDAV calendars and CalDAV, WebDAV for addressbooks is a compatible subset of CardDAV. Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN Does the name Pavlov ring a bell? 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] Categories
On Thu, 2011-06-23 at 07:14 -0400, Adam Tauno Williams wrote: When saving a task or event over a CalDAV collection Evolution sends a CATEGORIES attribute like: CLASS:PUBLIC CATEGORIES:Favorites\,Gifts\,Goals/Objectives PERCENT-COMPLETE:0 Looking at RFC2445 I'm pretty sure this is wrong. Shouldn't it be: CLASS:PUBLIC CATEGORIES:Favorite,Gifts,Goals/Objectives PERCENT-COMPLETE:0 From the RFC: Description: This property is used to specify categories or subtypes of the calendar component. The categories are useful in searching for a calendar component of a particular type and category. Within the VEVENT, VTODO or VJOURNAL calendar components, more than one category can be specified as a list of categories separated by the COMMA character (US-ASCII decimal 44). Example: The following are examples of this property: CATEGORIES:APPOINTMENT,EDUCATION Why is evolution escaping the comma? CATEGORIES:MEETING Yes, you should definitely file a bug report for this. RFC5545, which is the update to 2445, definitively makes this clear in section 3.8.1.2 as: Format Definition: This property is defined by the following notation: categories = CATEGORIES catparam : text *(, text) CRLF catparam = *( ; ; The following is OPTIONAL, ; but MUST NOT occur more than once. ; (; languageparam ) / ; ; The following is OPTIONAL, ; and MAY occur more than once. ; (; other-param) ; ) As well as giving the same example. Regards, Andrew McMillan. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN Flexibility is overrated. Constraints are liberating. 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] NO_THISANDFUTURE/THISANDPRIOR and file backend
On Thu, 2011-05-12 at 13:58 +0200, Patrick Ohly wrote: Hello! Why does the file backend claim that it doesn't support CAL_STATIC_CAPABILITY_NO_THISANDFUTURE and CAL_STATIC_CAPABILITY_NO_THISANDPRIOR? There is code for these in remove_object_instance_cb(), e_cal_backend_file_modify_object() and e_cal_backend_file_remove_object(). Is all of that dead code that was never used and tested? I don't need this feature, I just wonder. Hi Patrick, I have no idea either, but if anyone is thinking of changing it I note that THISANDPRIOR is deprecated as of RFC5545. Cheers, Andrew. -- http://andrew.mcmillan.net.nz/ Porirua, New Zealand Twitter: _karora Phone: +64(272)DEBIAN How many things I can do without! -- Socrates 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 requesting info on every year from 2011 down to 65535
On Mon, 2011-02-21 at 14:08 +0100, Carlos Martín Nieto wrote: On Thu, 2011-02-17 at 08:21 +0100, Milan Crha wrote: On Thu, 2011-02-17 at 00:48 +0100, Carlos Martín Nieto wrote: I've attached the backtrace for a year of 167 (I think) though I don't think it gives much information. This happens even if I have my main calendar off (which I think it's the only one with recurring events). Hi, this is from your CalDAV calendar, based on the backtrace. Try to get the component which is causing this trouble, and see whether there is something wrong either with that component or with evolution. You can achieve that if you breakpoint as you did earlier, then move to frame of e_cal_backend_sexp_match_comp function and invoke gdb command: (gdb) printf %s\n, e_cal_component_get_as_string (comp) then strip any private information (the best by replacing with 'x' or similar letter) and maybe share it here, if you think it's correct, or better file a bug report and post here a link to it. I'm not sure whose fault it is, but the RRULE:FREQ=WEEKLY;UNTIL=20110219;INTERVAL=-1;BYDAY=WE line looks suspicous. I've checked on the Google Calendar and even there it says it repeats each -1 weeks :S So I'm going to write up a patch to ignore intervals 0 (maybe 1 better?) Hi Carlos, From RFC5545: The INTERVAL rule part contains a positive integer representing at which intervals the recurrence rule repeats. The default value is 1, meaning every second for a SECONDLY rule, every minute for a MINUTELY rule, every hour for an HOURLY rule, every day for a DAILY rule, every week for a WEEKLY rule, every month for a MONTHLY rule, and every year for a YEARLY rule. For example, within a DAILY rule, a value of 8 means every eight days. So yes: 0 is also invalid, as you would expect :-) Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN To be is to program. 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] Multiple child-addressbooks under an account
On Sat, 2011-01-22 at 14:23 -0500, Adam Tauno Williams wrote: 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. I was under the impression that VTODO did support parent/child/sibling relationships. Like: http://tools.ietf.org/html/rfc5545.html#section-3.8.4.5 Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN All is fear in love and war. 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] Rethinking account management
On Wed, 2010-11-10 at 16:20 -0500, Matthew Barnes wrote: On Thu, 2010-11-11 at 09:16 +1300, Andrew McMillan wrote: Does this mean (for example) that we will be able to have a caldav server, with credentials, and then just associate (and maybe auto-discover) all of the user's addressbooks, calendars, todo-lists and journals which the user has on that server? I honestly don't know if that's possible with a CalDAV server (I'm just not familiar enough with CalDAV), but if we're talking about a groupware service... Yes, it is. Apple iCal (for example) will discover and show all of a user's calendar collections. The contacts app on an iPhone (with iOS 4.1) will discover and show all of a user's addressbooks if that DAV server also does CardDAV. Calendar collections may very well also store VTODO and VJOURNAL data (DAViCal does, for example, as well as supporting CardDAV in very recent versions). So Evolution, with SMTP, IMAP, CalDAV and CardDAV servers really is a complete groupware service. Newer extensions to CalDAV/CardDAV also add support for service discovery through SRV lookups for _caldav, _caldavs, _carddav, _carddavs services and URL locating through requests against /.well-known/carddav or /.well-known/caldav URLs after the server discovery. Currently each of our groupware backends has to invent this kind of account management for itself. All I'm proposing is a general framework that backends can utilize to make it easier and more consistent. Auto-discovery is also up to each backend to implement, and rightfully so. But the framework certainly allows for discovered data sources to be associated with the account. I hope I answered your question. Like I said, handling of groupware accounts is still kinda hand wavy at this point. I think so. Evolution was early to the party when CalDAV came out as a specification, but the support in there has not evolved very well to follow the current possibilities. That said, the biggest complaint I hear about Evolution's CalDAV support is it's lack of a useful 'offline' mode. I'm currently in the process of developing caldav/carddav setup and synchronisation process (for another purpose) but once that's working it might be worth looking at that with a view to seeing if we can improve the structure of CalDAV setup within Evolution. I know Milan has done some good work on CalDAV (and I'm very grateful for it) but I think the area needs some significant refactoring in the configuration and discovery parts. My biggest annoyance in there is that I go into a calendar and add a CalDAV server, and a collection, and then I go into tasks and add *the same* server, and *the same* collection, and then I go into Notes and add *the same server* and *the same collection* and then I go into the addressbook and add *the same server*, and (phew!) a different collection. There seems a little redundancy in that process, not least because for a given server I can discover all of a user's calendars and addressbooks, and whether they support calendar, tasks and/or notes by making two PROPFIND requests. Or maybe three requests, for a more recent server that allows discovery of the principal URL. Cheers, Andrew. -- http://andrew.mcmillan.net.nz/ Porirua, New Zealand Twitter: _karora Phone: +64(272)DEBIAN The real problem with hunting elephants is carrying the decoys. 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-kolab] Datastructures for calendar data
On Tue, 2010-10-05 at 10:58 +0200, Hendrik Helwich wrote: it is possible to store your own data in the kolab format [1] (Your own XML Tags and binary mail attachments). So we could preserve the timezone information from evolution iCalendar. But we still have the problem then that the time in some recurring events could be shown different in kontact and evolution in winter or summer time even if both clients are in the same time zone. Right now i see no acceptable workaround for this problem. Hi, I'm at CalConnect XIX right now with various calendaring people, lamenting (as we usually do) just how often people seem to think that storing data in UTC means you can forget the timezone. Is there any chance of fixing the Kolab format to include timezone information? It is an unfortunate breakage :-( If you are able to extend the format please be aware that an offset from UTC does not describe a timezone. I am currently at 4 hours behind UTC, but without knowing my latitude it would be impossible for you to say with certainty when (exactly) the fourth instance from now of a weekly repeating event would happen. If you hold the UTC time + some kind of identification for the timezone then there is probably usually sufficient information. It is also unfortunate that there are no canonical timezone identifiers at present, but for most people the Olson IDs are good enough. Regards, Andrew McMillan. -- http://andrew.mcmillan.net.nz/ Porirua, New Zealand Twitter: _karora Phone: +64(272)DEBIAN Whereof one cannot speak, thereon one must remain silent. -- Wittgenstein 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] FYI: new iCalendar
On Sat, 2009-09-26 at 14:22 -0400, Suman Manjunath wrote: On Sat, 2009-09-26 at 11:37 -0400, Matthew Barnes wrote: On Sat, 2009-09-26 at 15:21 +0200, Butrus Damaskus wrote: New version of iCalendar was accepted as RFC 5545 (see eg. http://www.rfc-editor.org/rfc/rfc5545.txt). Does this mean something for evolution development? :-o Looks like it's basically just errata from RFC 2445 (see page 166). I'm sure the corrections can be implemented or verified pretty easily. The burden may fall on the Free Association project as much as if not more so than on us. Wondering why it is an entirely new RFC for a bunch (11 to be precise) of errata. It could easily have been RFC 2445 spec 2 or something similar. That's the standard process for updating RFCs. You'll notice that it's been done the same way for RFC822 - 2822 and for DAV RFC2518 - 4918, etc. The last two digits of the original RFC number are maintained for mnemonic reasons during the process, too. Cheers, Andrew. http://andrew.mcmillan.net.nz/ Porirua, New Zealand Twitter: _karora Phone: +64(272)DEBIAN Necessity is the mother of documentation signature.asc Description: This is a digitally signed message part ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
