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] [PATCH][RFC] Deal with negative intervals
On Mon, 2011-02-21 at 17:28 +0100, Carlos Martín Nieto wrote: > Hi, > > Dealing with the error I posted about on another thread, I found that > Google is giving me some recurring events with an interval of -1, which > causes evo to search for all years from 2011 to -1, when it errors out > because it's no longer a valid time_t (which I guess also explains why > it sometimes seems to stop responding for a bit). > > I'm not sure how I managed to create them, but the Google calendar web > interface manages to display them correctly. As a fix for this > behaviour, I've changed the library to use the absolute value (which > also has the added advantage that these entries are now displayed). > > I can push the change in myself if people are in favour, but I wanted > to ask, as this could be considered quite wrong. +1 from me My only quibble is that any program should report on a client that creates bogus data, so I should like to see some kind of warning message written in the logs at this point. Cheers, Andrew. > >cmn > > --- > calendar/libecal/e-cal-recur.c |3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/calendar/libecal/e-cal-recur.c > b/calendar/libecal/e-cal-recur.c > index 3c30618..87e430c 100644 > --- a/calendar/libecal/e-cal-recur.c > +++ b/calendar/libecal/e-cal-recur.c > @@ -996,7 +996,8 @@ e_cal_recur_from_icalproperty (icalproperty *prop, > gboolean exception, > ir = icalproperty_get_rrule (prop); > > r->freq = ir.freq; > - r->interval = ir.interval; > + /* Invervals of -1 have been spotted in the wild (Google) */ > + r->interval = abs(ir.interval); > >r->enddate = e_cal_recur_obtain_enddate (&ir, prop, zone, > convert_end_date); > > ___ > evolution-hackers mailing list > evolution-hackers@gnome.org > To change your list options or unsubscribe, visit ... > http://mail.gnome.org/mailman/listinfo/evolution-hackers -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN The most common form of marriage proposal: "YOU'RE WHAT!?" 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] GroupWise mail issue (Was: (no subject))
On Wed, 2011-02-16 at 11:50 +0200, Antono Vasiljev wrote: > On Wed, 2011-02-16 at 07:29 +0100, Milan Crha wrote: > > > > Your last few mails are displayed as I have attached below in a > > > non-open mail client that I use (GroupWise). > > I guess it's the X-Face header doing trouble for GroupWise. > > I think that fetch and display gravatar (http://gravatar.com/) is much > better idea than attach X-Face to messages. > > What do You think? For free software I think Libravatar is a better choice than Gravatar. Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN Were there fewer fools, knaves would starve. -- Anonymous 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] Rethinking account management
On Wed, 2010-11-10 at 11:39 -0500, Matthew Barnes wrote: > > Backends can also define their own groups and schemas for storing > settings that are specific to that backend. Here's an off-the-cuff > example of what a source describing a CalDAV calendar might look like: > > [source]# org.gnome.Evolution.Source > name='My Calendar' > parent='caldav' > > [extensions/calendar] # org.gnome.Evolution.Source.Selectable > color='#e2f0d3' > enabled=true > > [extensions/caldav] # org.gnome.Evolution.Source.CalDAV > host='my.caldav.provider' > user='mbarnes' > path='/dav/mbarnes/Calendar' > ssl=true > ... > > (I'm leaning away from having URI keys, favoring instead URI components > as separate keys from which a complete URI string can be formed.) > > Here's where the hierarchy concept gets powerful. The source structure > for a groupware account providing integrated mail, calendars, contacts > (this is Exchange, GroupWise, perhaps someday Zimbra and Kolab, etc.) > might be a top-level source with groups defining a mail account with > server info and also any calendars or address books that you get by > default on the groupware account. Additional calendars or address books > or public mail folders for you or even other users on the server could > be implemented as child sources, such that disabling or deleting the > top-level mail account source affects the entire subtree of sources. 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? > This is getting a little hand wavy now because I've only just figured > out the file format and groupware integration is a ways off. But I hope > you can kinda see where I'm going with this and recognize its value over > what we have now. If what you're suggesting aligns with what I'm understanding, then the word "hallelujah" springs to mind :-) Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN Don't engineer in a crisis. -- Vint Cerf speaking on IPv6 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
Re: [Evolution-hackers] Configuration masquerading Data
On Wed, 2008-09-17 at 20:53 -0400, Martin Owens wrote: > > - Evolution Email Application > * Configuration - which services to connect to, which plugins to use, > syncing rates, display preferences. > * Data - Email messages recieved, contact data, calendar event, note > text, text typed in, files sent as attachments. Hi, I think it would be important to distinguish between a local cache of a remote IMAP or CalDAV folder (i.e. Configuration) vs. local mail folders, calendars, contact lists, etc. (Data). Cheers, Andrew. -------- Andrew @ McMillan .Net .NZ Porirua, New Zealand http://andrew.mcmillan.net.nz/Phone: +64(272)DEBIAN Today is the first day of the rest of the mess. 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
