* .ics export violates RFC2445
@ 2007-11-07 20:56 Adam Spiers
2007-11-10 10:07 ` Carsten Dominik
0 siblings, 1 reply; 15+ messages in thread
From: Adam Spiers @ 2007-11-07 20:56 UTC (permalink / raw)
To: org-mode mailing list
I use org-export-icalendar-combine-agenda-files to export my
appointments to an .ics file which I point korganizer at.
I noticed ages ago that if I have an appointment with a comma in, e.g.:
** <2007-12-07 Fri 20:00> foo, bar
korganizer always shows it as "bar" rather than "foo, bar". But I
never got round to investigating whether it was a bug with the export
or korganizer or something else ... until now :-) I just took a quick
look at the iCalendar spec, which is RFC2445, and discovered that the
SUMMARY field is defined as follows
summary = "SUMMARY" summparam ":" text CRLF
-- from http://tools.ietf.org/html/rfc2445#section-4.8.1.12
And the definition of 'text' in this context explicitly states that
several characters, including commas, need to be escaped with a
backslash:
http://tools.ietf.org/html/rfc2445#section-4.3.11
Sure enough, when I edited the .ics file and manually escaped the
comma, korganizer displayed the summary correctly.
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: .ics export violates RFC2445 2007-11-07 20:56 .ics export violates RFC2445 Adam Spiers @ 2007-11-10 10:07 ` Carsten Dominik 2008-04-29 14:12 ` Adam Spiers 0 siblings, 1 reply; 15+ messages in thread From: Carsten Dominik @ 2007-11-10 10:07 UTC (permalink / raw) To: Adam Spiers; +Cc: org-mode mailing list fixed, thanks - Carsten On 7Nov2007, at 9:56 PM, Adam Spiers wrote: > I use org-export-icalendar-combine-agenda-files to export my > appointments to an .ics file which I point korganizer at. > > I noticed ages ago that if I have an appointment with a comma in, > e.g.: > > ** <2007-12-07 Fri 20:00> foo, bar > > korganizer always shows it as "bar" rather than "foo, bar". But I > never got round to investigating whether it was a bug with the export > or korganizer or something else ... until now :-) I just took a quick > look at the iCalendar spec, which is RFC2445, and discovered that the > SUMMARY field is defined as follows > > summary = "SUMMARY" summparam ":" text CRLF > > -- from http://tools.ietf.org/html/rfc2445#section-4.8.1.12 > > And the definition of 'text' in this context explicitly states that > several characters, including commas, need to be escaped with a > backslash: > > http://tools.ietf.org/html/rfc2445#section-4.3.11 > > Sure enough, when I edited the .ics file and manually escaped the > comma, korganizer displayed the summary correctly. > > > _______________________________________________ > Emacs-orgmode mailing list > Remember: use `Reply All' to send replies to the list. > Emacs-orgmode@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-orgmode ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: .ics export violates RFC2445 2007-11-10 10:07 ` Carsten Dominik @ 2008-04-29 14:12 ` Adam Spiers 2008-04-29 15:52 ` Carsten Dominik 0 siblings, 1 reply; 15+ messages in thread From: Adam Spiers @ 2008-04-29 14:12 UTC (permalink / raw) To: org-mode mailing list Carsten Dominik (carsten.dominik@gmail.com) wrote: > On 7Nov2007, at 9:56 PM, Adam Spiers wrote: > >I use org-export-icalendar-combine-agenda-files to export my > >appointments to an .ics file which I point korganizer at. > > > >I noticed ages ago that if I have an appointment with a comma in, > >e.g.: > > > >** <2007-12-07 Fri 20:00> foo, bar > > > >korganizer always shows it as "bar" rather than "foo, bar". But I > >never got round to investigating whether it was a bug with the export > >or korganizer or something else ... until now :-) I just took a quick > >look at the iCalendar spec, which is RFC2445, and discovered that the > >SUMMARY field is defined as follows > > > > summary = "SUMMARY" summparam ":" text CRLF > > > > -- from http://tools.ietf.org/html/rfc2445#section-4.8.1.12 > > > >And the definition of 'text' in this context explicitly states that > >several characters, including commas, need to be escaped with a > >backslash: > > > > http://tools.ietf.org/html/rfc2445#section-4.3.11 > > > >Sure enough, when I edited the .ics file and manually escaped the > >comma, korganizer displayed the summary correctly. > > fixed, thanks > > - Carsten This appears to have regressed in some recent version ... Also, it would be great if a UID field could be generated for each event, perhaps by checksumming the contents of the event in some way. The RFC says: Conformance: The property MUST be specified in the "VEVENT", "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components. -- http://tools.ietf.org/html/rfc2445#section-4.8.4.7 The checksum would ensure that the UID field only changes when the event details check, which would be a first step towards helping synchronisation systems. I'm vaguely suspicious that the lack of UIDs currently confuses Google Calendar too. Thanks! ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: .ics export violates RFC2445 2008-04-29 14:12 ` Adam Spiers @ 2008-04-29 15:52 ` Carsten Dominik 2008-04-29 17:16 ` Adam Spiers 2008-04-30 18:38 ` .ics export violates RFC2445 Leo 0 siblings, 2 replies; 15+ messages in thread From: Carsten Dominik @ 2008-04-29 15:52 UTC (permalink / raw) To: Adam Spiers; +Cc: org-mode mailing list On Apr 29, 2008, at 4:12 PM, Adam Spiers wrote: > Carsten Dominik (carsten.dominik@gmail.com) wrote: >> On 7Nov2007, at 9:56 PM, Adam Spiers wrote: >>> I use org-export-icalendar-combine-agenda-files to export my >>> appointments to an .ics file which I point korganizer at. >>> >>> I noticed ages ago that if I have an appointment with a comma in, >>> e.g.: >>> >>> ** <2007-12-07 Fri 20:00> foo, bar >>> >>> korganizer always shows it as "bar" rather than "foo, bar". But I >>> never got round to investigating whether it was a bug with the >>> export >>> or korganizer or something else ... until now :-) I just took a >>> quick >>> look at the iCalendar spec, which is RFC2445, and discovered that >>> the >>> SUMMARY field is defined as follows >>> >>> summary = "SUMMARY" summparam ":" text CRLF >>> >>> -- from http://tools.ietf.org/html/rfc2445#section-4.8.1.12 >>> >>> And the definition of 'text' in this context explicitly states that >>> several characters, including commas, need to be escaped with a >>> backslash: >>> >>> http://tools.ietf.org/html/rfc2445#section-4.3.11 >>> >>> Sure enough, when I edited the .ics file and manually escaped the >>> comma, korganizer displayed the summary correctly. >> >> fixed, thanks >> >> - Carsten > > This appears to have regressed in some recent version ... Yes, seems there was still a bug. Fixed now. > > Also, it would be great if a UID field could be generated for each > event, perhaps by checksumming the contents of the event in some way. > The RFC says: > > Conformance: The property MUST be specified in the "VEVENT", > "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components. > > -- http://tools.ietf.org/html/rfc2445#section-4.8.4.7 > > The checksum would ensure that the UID field only changes when the > event details check, which would be a first step towards helping > synchronisation systems. I'm vaguely suspicious that the lack of UIDs > currently confuses Google Calendar too. A UID may be good. However I think changing the UID when changing the entry would be bad, because this would exactly *disable* synchronization. To synchronize, you must know which entries to compare, and this is only possible with a persistent UID. I guess we could create one, but this UID would then have to be stored in the entry, as a property. Exporting to ical again must then re-use the old uid each time. My org-id.el in the contrib directory allows already to create unique identifiers, and it would be easy enough to include the domain to make them truely unique, wordwide. However, right now I am hesitating to force a property drawer onto every entry that ever is exported to iCalendar. But as an option, this might really be good and eventually allow true synchronization. - Carsten P.S. Adam, I emailed you twice privately in the last few weeks, but did not get any reply. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: .ics export violates RFC2445 2008-04-29 15:52 ` Carsten Dominik @ 2008-04-29 17:16 ` Adam Spiers 2008-05-15 8:33 ` Carsten Dominik 2008-04-30 18:38 ` .ics export violates RFC2445 Leo 1 sibling, 1 reply; 15+ messages in thread From: Adam Spiers @ 2008-04-29 17:16 UTC (permalink / raw) To: org-mode mailing list Carsten Dominik (dominik@science.uva.nl) wrote: > On Apr 29, 2008, at 4:12 PM, Adam Spiers wrote: > >Carsten Dominik (carsten.dominik@gmail.com) wrote: > >>On 7Nov2007, at 9:56 PM, Adam Spiers wrote: > >>>I use org-export-icalendar-combine-agenda-files to export my > >>>appointments to an .ics file which I point korganizer at. > >>> > >>>I noticed ages ago that if I have an appointment with a comma in, > >>>e.g.: > >>> > >>>** <2007-12-07 Fri 20:00> foo, bar > >>> > >>>korganizer always shows it as "bar" rather than "foo, bar". But I > >>>never got round to investigating whether it was a bug with the > >>>export or korganizer or something else ... until now :-) I just took a > >>>quick look at the iCalendar spec, which is RFC2445, and discovered that > >>>the SUMMARY field is defined as follows > >>> > >>> summary = "SUMMARY" summparam ":" text CRLF > >>> > >>> -- from http://tools.ietf.org/html/rfc2445#section-4.8.1.12 > >>> > >>>And the definition of 'text' in this context explicitly states that > >>>several characters, including commas, need to be escaped with a > >>>backslash: > >>> > >>> http://tools.ietf.org/html/rfc2445#section-4.3.11 > >>> > >>>Sure enough, when I edited the .ics file and manually escaped the > >>>comma, korganizer displayed the summary correctly. > >> > >>fixed, thanks > >> > >>- Carsten > > > >This appears to have regressed in some recent version ... > > Yes, seems there was still a bug. Fixed now. Works great, thanks! > >Also, it would be great if a UID field could be generated for each > >event, perhaps by checksumming the contents of the event in some way. > >The RFC says: > > > > Conformance: The property MUST be specified in the "VEVENT", > > "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components. > > > > -- http://tools.ietf.org/html/rfc2445#section-4.8.4.7 > > > >The checksum would ensure that the UID field only changes when the > >event details check, which would be a first step towards helping > >synchronisation systems. I'm vaguely suspicious that the lack of UIDs > >currently confuses Google Calendar too. > > A UID may be good. However I think changing the UID when changing the > entry would be bad, because this would exactly *disable* synchronization. > To synchronize, you must know which entries to compare, and this is only > possible with a persistent UID. Doh - you are right of course. > I guess we could create one, but this UID would then have to be stored > in the entry, as a property. Exporting to ical again must then re-use the > old uid each time. > > My org-id.el in the contrib directory allows already to create unique > identifiers, and it would be easy enough to include the domain to make > them truely unique, wordwide. > > However, right now I am hesitating to force a property drawer onto > every entry that ever is exported to iCalendar. But as an option, this might > really be good and eventually allow true synchronization. I understand your hesitation - as an option that sounds perfect. I forgot to mention before that gcaldaemon http://gcaldaemon.sourceforge.net/ which is a very nice piece of software indeed, requires the UID field. If you provided that, then gcaldaemon would give us the solution to at least unidirectional synchronisation with Google Calendar. I have experimented with simply scp'ing the generated .ics file to a private location on my webserver and pointing Google Calendar at that private URL, but there is no way to force Google Calendar to reload the data after subsequent scp invocations. > P.S. Adam, I emailed you twice privately in the last few weeks, but > did not get any reply. Hrm :-/ I have issues with private mail currently due to receiving between 5,000 and 10,000 spam a day (not to mention being busy and still having yet to perfect GTD ;-). However I just replied to a couple of recent ones - were they the ones you were referring to? ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: .ics export violates RFC2445 2008-04-29 17:16 ` Adam Spiers @ 2008-05-15 8:33 ` Carsten Dominik 2008-05-27 21:55 ` Adam Spiers 0 siblings, 1 reply; 15+ messages in thread From: Carsten Dominik @ 2008-05-15 8:33 UTC (permalink / raw) To: Adam Spiers; +Cc: org-mode mailing list On Apr 29, 2008, at 7:16 PM, Adam Spiers wrote: >>> Also, it would be great if a UID field could be generated for each >>> event, perhaps by checksumming the contents of the event in some >>> way. >>> The RFC says: >>> >>> Conformance: The property MUST be specified in the "VEVENT", >>> "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components. >>> >>> -- http://tools.ietf.org/html/rfc2445#section-4.8.4.7 >>> >>> The checksum would ensure that the UID field only changes when the >>> event details check, which would be a first step towards helping >>> synchronisation systems. I'm vaguely suspicious that the lack of >>> UIDs >>> currently confuses Google Calendar too. >> >> A UID may be good. However I think changing the UID when changing >> the >> entry would be bad, because this would exactly *disable* >> synchronization. >> To synchronize, you must know which entries to compare, and this is >> only >> possible with a persistent UID. > > Doh - you are right of course. > >> I guess we could create one, but this UID would then have to be >> stored >> in the entry, as a property. Exporting to ical again must then re- >> use the >> old uid each time. >> >> My org-id.el in the contrib directory allows already to create unique >> identifiers, and it would be easy enough to include the domain to >> make >> them truely unique, wordwide. >> >> However, right now I am hesitating to force a property drawer onto >> every entry that ever is exported to iCalendar. But as an option, >> this might >> really be good and eventually allow true synchronization. > > I understand your hesitation - as an option that sounds perfect. Please get the latest GIT version of Org. Then set the variable (setq org-icalendar-force-UID t) and try to export to iCalendar. Right now, I am only forcing and using the ID for VEVENT. I am not using it for VTODO, because I am not sure if it is allowed to have the same UID for a VEVENT and a VTODO, if they originate from the same entry in a database? Do you or anyone else know what the rules are for this? - Carsten ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: .ics export violates RFC2445 2008-05-15 8:33 ` Carsten Dominik @ 2008-05-27 21:55 ` Adam Spiers 2008-05-27 22:25 ` 1-way syncing with google calendar (was Re: .ics export violates RFC2445) Adam Spiers 0 siblings, 1 reply; 15+ messages in thread From: Adam Spiers @ 2008-05-27 21:55 UTC (permalink / raw) To: org-mode mailing list On Thu, May 15, 2008 at 10:33:17AM +0200, Carsten Dominik wrote: > On Apr 29, 2008, at 7:16 PM, Adam Spiers wrote: > >>>Also, it would be great if a UID field could be generated for each > >>>event, perhaps by checksumming the contents of the event in some > >>>way. [snipped] > >>I guess we could create one, but this UID would then have to be > >>stored in the entry, as a property. Exporting to ical again must > >>then re- use the old uid each time. > >> > >>My org-id.el in the contrib directory allows already to create > >>unique identifiers, and it would be easy enough to include the > >>domain to make them truely unique, wordwide. > >> > >>However, right now I am hesitating to force a property drawer onto > >>every entry that ever is exported to iCalendar. But as an option, > >>this might really be good and eventually allow true > >>synchronization. > > > >I understand your hesitation - as an option that sounds perfect. > > Please get the latest GIT version of Org. Then set the variable > > (setq org-icalendar-force-UID t) > > and try to export to iCalendar. > > Right now, I am only forcing and using the ID for VEVENT. I am not > using it for VTODO, because I am not sure if it is allowed to have the > same UID for a VEVENT and a VTODO, if they originate from the same > entry in a database? Do you or anyone else know what the rules are > for this? Sorry it took me a while to test this - things have been crazy recently. From the release notes it looks like you already decided to generate unique UIDs for each source, which is fantastic - sounds like the safe thing to do, regardless of what the official spec requirements are. I'm happy to report that using UIDs fixes the issue I was seeing with duplicate entries in korganizer: http://bugs.kde.org/show_bug.cgi?id=99649 I'm going to restart gcaldaemon shortly - if it works then orgmode can boast unidirectional non-interactive syncing with google calendar! (as opposed to repeatedly importing an .ics file manually, which is very tedious). ^ permalink raw reply [flat|nested] 15+ messages in thread
* 1-way syncing with google calendar (was Re: .ics export violates RFC2445) 2008-05-27 21:55 ` Adam Spiers @ 2008-05-27 22:25 ` Adam Spiers 2008-05-28 21:02 ` Cezar Halmagean 0 siblings, 1 reply; 15+ messages in thread From: Adam Spiers @ 2008-05-27 22:25 UTC (permalink / raw) To: emacs-orgmode On Tue, May 27, 2008 at 10:55:57PM +0100, Adam Spiers wrote: > I'm going to restart gcaldaemon shortly - if it works then orgmode can > boast unidirectional non-interactive syncing with google calendar! (as > opposed to repeatedly importing an .ics file manually, which is very > tedious). Hooray, it works! org-icalendar-force-UID + gcaldaemon gives nice unidirectional non-interactive syncing with google calendar. Here's a snippet from the log: DEBUG | Updating event ( test thing!) in Google Calendar... DEBUG | Synchronization finished. DEBUG | Starting Google Calendar synchronizer... DEBUG | Connecting to Google... [snipped] DEBUG | Found event (S: NEXT [#C] feedbac...) in Google Calendar by 5 concordant property. DEBUG | Found event (S: NEXT [#A] tax ret...) in Google Calendar by 4 concordant property. DEBUG | Found event (DL: NEXT [#A] tax re...) in Google Calendar by 4 concordant property. [snipped] DEBUG | Found event ( unavailable all mor...) in Google Calendar by 4 concordant property. DEBUG | Found event ( RX6RSCQUGQXIDYWT) in Google Calendar by 4 concordant property. DEBUG | Found event ( 6ZB7TTBGS3NQI9S9) in Google Calendar by 4 concordant property. DEBUG | Found event (S: NEXT [#A] ring Ri...) in Google Calendar by 4 concordant property. DEBUG | Found event (S: WAITING [#B] book...) in Google Calendar by 4 concordant property. DEBUG | Found event (S: DONE [#A] try to ...) in Google Calendar by 5 concordant property. DEBUG | Found event (S: CANCELLED [#A] ph...) in Google Calendar by 4 concordant property. DEBUG | Found event (DL: WAITING [#B] boo...) in Google Calendar by 4 concordant property. DEBUG | Found event (S: NEXT [#B] new sof...) in Google Calendar by 4 concordant property. DEBUG | Found event (S: PROJECT [#B] balc...) in Google Calendar by 4 concordant property. DEBUG | Updating event (S: PROJECT [#B] balc...) in Google Calendar... DEBUG | Updating event (S: CANCELLED [#A] ph...) in Google Calendar... DEBUG | Updating event (S: NEXT [#A] tax ret...) in Google Calendar... DEBUG | Updating event (DL: NEXT [#A] tax re...) in Google Calendar... DEBUG | Synchronization finished. gcaldaemon has a very nice intuitive GUI config editor. The only gotcha I found was that I had to hack the shell wrappers to use a newer java binary than the one on my default path. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 1-way syncing with google calendar (was Re: .ics export violates RFC2445) 2008-05-27 22:25 ` 1-way syncing with google calendar (was Re: .ics export violates RFC2445) Adam Spiers @ 2008-05-28 21:02 ` Cezar Halmagean 2008-05-28 21:57 ` Adam Spiers 0 siblings, 1 reply; 15+ messages in thread From: Cezar Halmagean @ 2008-05-28 21:02 UTC (permalink / raw) To: emacs-orgmode Adam Spiers <orgmode@adamspiers.org> writes: > On Tue, May 27, 2008 at 10:55:57PM +0100, Adam Spiers wrote: >> I'm going to restart gcaldaemon shortly - if it works then orgmode can >> boast unidirectional non-interactive syncing with google calendar! (as >> opposed to repeatedly importing an .ics file manually, which is very >> tedious). > > Hooray, it works! org-icalendar-force-UID + gcaldaemon gives nice > unidirectional non-interactive syncing with google calendar. Here's a > snippet from the log: > > DEBUG | Updating event ( test thing!) in Google Calendar... > DEBUG | Synchronization finished. > DEBUG | Starting Google Calendar synchronizer... > DEBUG | Connecting to Google... Does this work both ways ? org -> google and google -> org ? Can you provide your changes/settings ? Thanks ! Cezar ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Re: 1-way syncing with google calendar (was Re: .ics export violates RFC2445) 2008-05-28 21:02 ` Cezar Halmagean @ 2008-05-28 21:57 ` Adam Spiers 2008-05-29 10:32 ` Tim O'Callaghan 0 siblings, 1 reply; 15+ messages in thread From: Adam Spiers @ 2008-05-28 21:57 UTC (permalink / raw) To: emacs-orgmode On Wed, May 28, 2008 at 02:02:01PM -0700, Cezar Halmagean wrote: > Adam Spiers <orgmode@adamspiers.org> writes: > > > On Tue, May 27, 2008 at 10:55:57PM +0100, Adam Spiers wrote: > >> I'm going to restart gcaldaemon shortly - if it works then orgmode can > >> boast unidirectional non-interactive syncing with google calendar! (as > >> opposed to repeatedly importing an .ics file manually, which is very > >> tedious). > > > > Hooray, it works! org-icalendar-force-UID + gcaldaemon gives nice > > unidirectional non-interactive syncing with google calendar. Here's a ^^^^^^^^^^^^^^ Always remember to read the small print ;-) > > snippet from the log: > > > > DEBUG | Updating event ( test thing!) in Google Calendar... > > DEBUG | Synchronization finished. > > DEBUG | Starting Google Calendar synchronizer... > > DEBUG | Connecting to Google... > > Does this work both ways ? org -> google and google -> org ? No, just org -> google as per above. See also http://article.gmane.org/gmane.emacs.orgmode/6817 > Can you provide your changes/settings ? The only setting is org-icalendar-force-UID as mentioned above. Configuration of gcaldaemon is straightforward, and it should work out of the box. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Re: 1-way syncing with google calendar (was Re: .ics export violates RFC2445) 2008-05-28 21:57 ` Adam Spiers @ 2008-05-29 10:32 ` Tim O'Callaghan 2008-05-29 13:08 ` Re: 1-way syncing with google calendar David Smith 0 siblings, 1 reply; 15+ messages in thread From: Tim O'Callaghan @ 2008-05-29 10:32 UTC (permalink / raw) To: emacs-orgmode Cool - just caught up with this. If you check the archives i had a very basic google->org solution using w3. I stopped using it when i moved back to Emacs, guess its time to dig it out :) Tim. 2008/5/28 Adam Spiers <orgmode@adamspiers.org>: > On Wed, May 28, 2008 at 02:02:01PM -0700, Cezar Halmagean wrote: >> Adam Spiers <orgmode@adamspiers.org> writes: >> >> > On Tue, May 27, 2008 at 10:55:57PM +0100, Adam Spiers wrote: >> >> I'm going to restart gcaldaemon shortly - if it works then orgmode can >> >> boast unidirectional non-interactive syncing with google calendar! (as >> >> opposed to repeatedly importing an .ics file manually, which is very >> >> tedious). >> > >> > Hooray, it works! org-icalendar-force-UID + gcaldaemon gives nice >> > unidirectional non-interactive syncing with google calendar. Here's a > ^^^^^^^^^^^^^^ > Always remember to read the small print ;-) > >> > snippet from the log: >> > >> > DEBUG | Updating event ( test thing!) in Google Calendar... >> > DEBUG | Synchronization finished. >> > DEBUG | Starting Google Calendar synchronizer... >> > DEBUG | Connecting to Google... >> >> Does this work both ways ? org -> google and google -> org ? > > No, just org -> google as per above. > > See also http://article.gmane.org/gmane.emacs.orgmode/6817 > >> Can you provide your changes/settings ? > > The only setting is org-icalendar-force-UID as mentioned above. > Configuration of gcaldaemon is straightforward, and it should work out > of the box. > > > _______________________________________________ > Emacs-orgmode mailing list > Remember: use `Reply All' to send replies to the list. > Emacs-orgmode@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-orgmode > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Re: 1-way syncing with google calendar 2008-05-29 10:32 ` Tim O'Callaghan @ 2008-05-29 13:08 ` David Smith 2008-05-30 20:55 ` Adam Spiers 2009-03-20 15:18 ` David Abrahams 0 siblings, 2 replies; 15+ messages in thread From: David Smith @ 2008-05-29 13:08 UTC (permalink / raw) To: Tim O'Callaghan; +Cc: emacs-orgmode [-- Attachment #1.1: Type: text/plain, Size: 2333 bytes --] "Tim O'Callaghan" <tim.ocallaghan@gmail.com> writes: > Cool - just caught up with this. > > If you check the archives i had a very basic google->org solution using w3. > > I stopped using it when i moved back to Emacs, guess its time to dig it out :) I'm currently building something similar using g-client which is much easier to integrate with the emacs calendar. It should also be able to do two-way sync without an external daemon. I just haven't found a good way to integrate it with the agenda. Anyone have experience with it? - dds > > 2008/5/28 Adam Spiers <orgmode@adamspiers.org>: >> On Wed, May 28, 2008 at 02:02:01PM -0700, Cezar Halmagean wrote: >>> Adam Spiers <orgmode@adamspiers.org> writes: >>> >>> > On Tue, May 27, 2008 at 10:55:57PM +0100, Adam Spiers wrote: >>> >> I'm going to restart gcaldaemon shortly - if it works then orgmode can >>> >> boast unidirectional non-interactive syncing with google calendar! (as >>> >> opposed to repeatedly importing an .ics file manually, which is very >>> >> tedious). >>> > >>> > Hooray, it works! org-icalendar-force-UID + gcaldaemon gives nice >>> > unidirectional non-interactive syncing with google calendar. Here's a >> ^^^^^^^^^^^^^^ >> Always remember to read the small print ;-) >> >>> > snippet from the log: >>> > >>> > DEBUG | Updating event ( test thing!) in Google Calendar... >>> > DEBUG | Synchronization finished. >>> > DEBUG | Starting Google Calendar synchronizer... >>> > DEBUG | Connecting to Google... >>> >>> Does this work both ways ? org -> google and google -> org ? >> >> No, just org -> google as per above. >> >> See also http://article.gmane.org/gmane.emacs.orgmode/6817 >> >>> Can you provide your changes/settings ? >> >> The only setting is org-icalendar-force-UID as mentioned above. >> Configuration of gcaldaemon is straightforward, and it should work out >> of the box. >> >> >> _______________________________________________ >> Emacs-orgmode mailing list >> Remember: use `Reply All' to send replies to the list. >> Emacs-orgmode@gnu.org >> http://lists.gnu.org/mailman/listinfo/emacs-orgmode >> > > > _______________________________________________ > Emacs-orgmode mailing list > Remember: use `Reply All' to send replies to the list. > Emacs-orgmode@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-orgmode [-- Attachment #1.2: Type: application/pgp-signature, Size: 480 bytes --] [-- Attachment #2: Type: text/plain, Size: 204 bytes --] _______________________________________________ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Re: 1-way syncing with google calendar 2008-05-29 13:08 ` Re: 1-way syncing with google calendar David Smith @ 2008-05-30 20:55 ` Adam Spiers 2009-03-20 15:18 ` David Abrahams 1 sibling, 0 replies; 15+ messages in thread From: Adam Spiers @ 2008-05-30 20:55 UTC (permalink / raw) To: emacs-orgmode On Thu, May 29, 2008 at 10:08:48PM +0900, David Smith wrote: > "Tim O'Callaghan" <tim.ocallaghan@gmail.com> writes: > > > Cool - just caught up with this. > > > > If you check the archives i had a very basic google->org solution using w3. > > > > I stopped using it when i moved back to Emacs, guess its time to dig it out :) > > I'm currently building something similar using g-client which is much > easier to integrate with the emacs calendar. It should also be able to > do two-way sync without an external daemon. I just haven't found a good > way to integrate it with the agenda. Anyone have experience with it? No, but please let us know as soon as you have something worth testing! For google->org, I was thinking that you would need to impose some structure on the org representation of events, so that it was clear algorithmically where to insert new events within the org buffer that were only on the google side prior to syncing. A simple chronologically sorted format would suffice, e.g. * <2008-05-30 Fri> foo * <2008-05-31 Sat> bar * <2008-06-01 Sun> baz or * 2008-05 ** <2008-05-30 Fri> foo ** <2008-05-31 Sat> bar * 2008-06 ** <2008-06-01 Sun> baz or even * 2008 ** 2008-05 *** <2008-05-30 Fri> foo *** <2008-05-31 Sat> bar ** 2008-06 *** <2008-06-01 Sun> baz ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 1-way syncing with google calendar 2008-05-29 13:08 ` Re: 1-way syncing with google calendar David Smith 2008-05-30 20:55 ` Adam Spiers @ 2009-03-20 15:18 ` David Abrahams 1 sibling, 0 replies; 15+ messages in thread From: David Abrahams @ 2009-03-20 15:18 UTC (permalink / raw) To: emacs-orgmode; +Cc: dds on Thu May 29 2008, David Smith <dds-AT-google.com> wrote: > "Tim O'Callaghan" <tim.ocallaghan@gmail.com> writes: > >> Cool - just caught up with this. >> >> If you check the archives i had a very basic google->org solution using w3. >> >> I stopped using it when i moved back to Emacs, guess its time to dig it out :) > > I'm currently building something similar using g-client which is much > easier to integrate with the emacs calendar. It should also be able to > do two-way sync without an external daemon. I just haven't found a good > way to integrate it with the agenda. Anyone have experience with it? David, did you ever get anywhere with this? I'm very interested in such a solution and might pick up where you left off if it's not already finished. Thanks, -- Dave Abrahams BoostPro Computing http://www.boostpro.com ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: .ics export violates RFC2445 2008-04-29 15:52 ` Carsten Dominik 2008-04-29 17:16 ` Adam Spiers @ 2008-04-30 18:38 ` Leo 1 sibling, 0 replies; 15+ messages in thread From: Leo @ 2008-04-30 18:38 UTC (permalink / raw) To: emacs-orgmode On 2008-04-29 16:52 +0100, Carsten Dominik wrote: > A UID may be good. However I think changing the UID when changing the > entry would be bad, because this would exactly *disable* > synchronization. > To synchronize, you must know which entries to compare, and this is only > possible with a persistent UID. > > I guess we could create one, but this UID would then have to be > stored in the > entry, as a property. Exporting to ical again must then re-use the > old uid each time. > > My org-id.el in the contrib directory allows already to create unique > identifiers, and it would be easy enough to include the domain to > make them truely > unique, wordwide. > > However, right now I am hesitating to force a property drawer onto > every entry > that ever is exported to iCalendar. But as an option, this might > really be > good and eventually allow true synchronization. For people that don't have constant access to computer, syncing with systems like google calendar seems extremely helpful. So I really look forward to a clean solution on this matter. For example, shall we divide the package into two: outliner and organiser? Just a thought. Best wishes, -- .: Leo :. [ sdl.web AT gmail.com ] .: [ GPG Key: 9283AA3F ] :. Use the better alternative -- http://www.openoffice.org/ ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2009-03-20 15:20 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-11-07 20:56 .ics export violates RFC2445 Adam Spiers 2007-11-10 10:07 ` Carsten Dominik 2008-04-29 14:12 ` Adam Spiers 2008-04-29 15:52 ` Carsten Dominik 2008-04-29 17:16 ` Adam Spiers 2008-05-15 8:33 ` Carsten Dominik 2008-05-27 21:55 ` Adam Spiers 2008-05-27 22:25 ` 1-way syncing with google calendar (was Re: .ics export violates RFC2445) Adam Spiers 2008-05-28 21:02 ` Cezar Halmagean 2008-05-28 21:57 ` Adam Spiers 2008-05-29 10:32 ` Tim O'Callaghan 2008-05-29 13:08 ` Re: 1-way syncing with google calendar David Smith 2008-05-30 20:55 ` Adam Spiers 2009-03-20 15:18 ` David Abrahams 2008-04-30 18:38 ` .ics export violates RFC2445 Leo
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).