.ics export violates RFC2445

.ics export violates RFC2445

[Adam Spiers]

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.

Re: .ics export violates RFC2445

[Carsten Dominik]

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

Re: .ics export violates RFC2445

[Adam Spiers]

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!

Re: .ics export violates RFC2445

[Carsten Dominik]

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.

Re: .ics export violates RFC2445

[Adam Spiers]

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?

Re: .ics export violates RFC2445

[Leo]

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/

Re: .ics export violates RFC2445

[Carsten Dominik]

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

Re: .ics export violates RFC2445

[Adam Spiers]

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

1-way syncing with google calendar (was Re: .ics export violates RFC2445)

[Adam Spiers]

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.

Re: 1-way syncing with google calendar (was Re: .ics export violates RFC2445)

[Cezar Halmagean]

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

Re: Re: 1-way syncing with google calendar (was Re: .ics export violates RFC2445)

[Adam Spiers]

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.

Re: Re: 1-way syncing with google calendar (was Re: .ics export violates RFC2445)

[Tim O'Callaghan]

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
>

Re: Re: 1-way syncing with google calendar

[David Smith]

[-- 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

Re: Re: 1-way syncing with google calendar

[Adam Spiers]

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

Re: 1-way syncing with google calendar

[David Abrahams]

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