emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* .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 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

* 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

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).