On Nov 19, 2006, at 2:46 PM, Erik Harg wrote:
On Nov 19, 2006, at 2:20 PM, Lennart Regebro wrote:
Erik Harg wrote:
My mistake, that CalDAV stuff... Well, I must admit that I lack
some insight into the finer details of the various calendar
synchronization methods, so maybe you would care to explain what
synchronization features I should look for in a calendar app, to
make it compatible with CPSSharedCalendar?
CPSSharedCalendar can import and export iCalendar files via HTTP
and WebDAV, which is what most iCalendar applications support.
Thank you, Lennart! Ok, and then I suppose that the WebDAV feature
is what, for instance, Mozilla Sunbird is using to communicate with
CPSSharedCalendar? (When Sunbird is working...) Allright, then I
just need to find an iCalendar application that supports WebDAV
*and* is sufficiently stable on my Macs... :-)
Oh, and, in the Readme section of the Chandler website [1], it
says that it is compatible with that project's Cosmo server, as
well as "other WebDAV and CALDAV servers". I guess that means
that CPSSharedCalendar is not supported.
Well, they could mean that the can upload iCalendar files with
WebDAV, which should work.
I guess they could mean that, yes... :-)
Well, I guess I'll have to ask them, if I can just find the right
list for contacting the Chandler developers about stuff like this.
Hi again everyone. I have now debugged this issue with the Chandler
developers, and we have come to the conclusion that this should
definately work as far as the iCalendar/WebDAV communication goes,
but that it fails at two levels. The fault is Chandler's alone (and
the HTTP library they're using), but I have a suggestion for
CPSSharedCalendar that might give a workaround for the problem.
The two failures are in Chandler's use of the calendar "subscription
URL" one enters in the application; basically, it sees if the last
four characters are ".ics", and if it is, it tries to access the URL
as an iCalendar file with WebDAV. So, when the CPSSharedCalendar
export URL ends with "...__=1" (as in "...?disable_cookie_login__=1),
Chandler didn't understand what to do with it. Well, I then fed it a
URL with "&chandler=.ics" appended, and it got it. However, the
underlaying HTTP transport library didn't care much for URL query
parameters, and so everything from the "?disable..." on got purged
before the request was sent to the server. Therefore, CPS tried to
redirect Chandler's request to the login page, which the calendar app
in turn didn't get much sense out of, understandably. :-)
Well, to get to the point, my hope is that while we're (at least I
am) waiting for the OSAF guys developing Chandler to fix their HTTP
URL behaviour, someone will point me in the right direction for
adding some kind of control on the iCalendar export on the CPS side
that will allow me to get around this problem. Either, I am thinking,
through forcing CPS into the disable_cookie_login mode when the URL
contains the "...calendar/calendar.ics" string, or through some kind
of different URL rewriting method (or what it should be called) that
enables me to use a different URL for the iCalendar export that does
not need the URL parameters (e.g. ".../calendar/export/
calendar.ics"?). So, does anyone care to help me? Thank you! :-)
Best regards,
--
Erik Harg
General Manager
TerraVision AS
t. +47 4000 3836
m. +47 924 98 541
e. [EMAIL PROTECTED]
_______________________________________________
cps-users mailing list
[email protected]
http://lists.nuxeo.com/mailman/listinfo/cps-users
