Mailing List Archive

On Tue, 2010-11-09 at 10:23 +0100, Matthias Althaus wrote:
> Hey there,
>
> after playing around with Davical some months ago, I'm now back on its implementation. The reading part was easy, updating events is also working, but I cannot get adding new events to work out.
>
> I'm sending a PUT with this body:
>
> BEGIN:VCALENDAR
> PRODID:-//davical.org//NONSGML AWL Calendar//EN
> VERSION:2.0
> CALSCALE:GREGORIAN
> BEGIN:VEVENT
> SUMMARY:PUTtest
> CREATED:20101109T090607Z
> DTSTART;TZID=Europe/Berlin:20101116T121000
> DTEND;TZID=Europe/Berlin:20101116T131000
> END:VEVENT
> END:VCALENDAR
>
> The answer from the server then is
>
> HTTP/1.1 201 Created
> Date: Tue, 09 Nov 2010 09:06:07 GMT
> Server: Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny9 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g
> X-Powered-By: PHP/5.2.6-1+lenny9
> DAV: 1, 2, access-control, calendar-access, calendar-schedule, extended-mkcol, calendar-proxy, bind, calendar-auto-schedule
> X-DAViCal-Version: DAViCal/0.9.9; DB/1.2.8
> Content-Length: 0
> Connection: close
> Content-Type: text/plain; charset="utf-8"
>
> ... but it's not sending an etag. I checked the log and compared it
> with adding a even through Sunbird.

This bug is fixed in Git, and until it was fixed it would only send an
etag response if you identified your content as text/calendar, so I
suspect you're not sending a 'Content-type' header :-)

Regards,
Andrew McMillan.

--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Kill Ugly Processor Architectures
-- Karl Lehenbauer
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-dev/attachments/20101110/a23c985e/attachment.pgp>

Matthias,

What does the rest of your PUT request look like? What are the headers?
Using the your request body and the following headers

Host: davical.example.com
Content-Type: text/calendar; charset="utf-8"

using curl...

curl -i -T test_dav_put -X "PUT /caldav.php/mulroony/home/12350
HTTP/1.1" https://..../caldav.php/mulroony/home/ -H "Host:
davical.example.com" -H "Content-Type: text/calendar; charset=\"utf-8\""

Returns the results.

HTTP/1.1 201 Created
Date: Wed, 10 Nov 2010 16:46:44 GMT
Server: Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.12 with Suhosin-Patch
mod_ssl/2.2.8 OpenSSL/0.9.8g
X-Powered-By: PHP/5.2.4-2ubuntu5.12
DAV: 1, 2, access-control, calendar-access, calendar-schedule,
extended-mkcol, calendar-proxy, bind
ETag: "d74e038253992977f4ebe8964e504103"
X-DAViCal-Version: DAViCal/0.9.9; DB/1.2.8
Content-Length: 0
Content-Type: text/plain; charset="utf-8"

I think that header line is added in one of the last lines of
'inc/caldav-PUT.php', but I might be wrong.

95: header(sprintf('ETag: "%s"', $etag) );

Pat

On 11/09/2010 05:00 PM, davical-dev-request at lists.morphoss.com wrote:
> Date: Tue, 09 Nov 2010 10:23:03 +0100
> From: "Matthias Althaus"<matthias.althaus at iserv.eu>
> Subject: [Davical-dev] PUTing new event to collection
> To:davical-dev at lists.morphoss.com
> Message-ID:<iserv-20101109.102303-ee0756657c51fa16 at iserv.eu>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hey there,
>
> after playing around with Davical some months ago, I'm now back on its implementation. The reading part was easy, updating events is also working, but I cannot get adding new events to work out.
>
> I'm sending a PUT with this body:
>
> BEGIN:VCALENDAR
> PRODID:-//davical.org//NONSGML AWL Calendar//EN
> VERSION:2.0
> CALSCALE:GREGORIAN
> BEGIN:VEVENT
> SUMMARY:PUTtest
> CREATED:20101109T090607Z
> DTSTART;TZID=Europe/Berlin:20101116T121000
> DTEND;TZID=Europe/Berlin:20101116T131000
> END:VEVENT
> END:VCALENDAR
>
> The answer from the server then is
>
> HTTP/1.1 201 Created
> Date: Tue, 09 Nov 2010 09:06:07 GMT
> Server: Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny9 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g
> X-Powered-By: PHP/5.2.6-1+lenny9
> DAV: 1, 2, access-control, calendar-access, calendar-schedule, extended-mkcol, calendar-proxy, bind, calendar-auto-schedule
> X-DAViCal-Version: DAViCal/0.9.9; DB/1.2.8
> Content-Length: 0
> Connection: close
> Content-Type: text/plain; charset="utf-8"
>
> ... but it's not sending an etag. I checked the log and compared it with adding a even through Sunbird.
>
>
>
> On the communication side the only real difference is that SB is sending a VTIMEZONE with the event which I'm omitting.
>
> The log is showing that my event got added to caldav_data with an etag. Then he's done and sends the 201. With SB the data is also added to caldav_item and he's including the etag into the response.
>
> What am I doing wrong? Why the difference? Is VTIMEZONE required? And why is the RFC 4791 sometimes pretty useless?
>
> I couldn't track the problem down yet, but I'll add some more debug logging to Davical now.
>
> Best regards
> Matthias
>
>
> ------------------------------

Hey again,

> This bug is fixed in Git, and until it was fixed it would only send an
> etag response if you identified your content as text/calendar, so I
> suspect you're not sending a 'Content-type' header :-)
Yes and no. At the moment I'm using a Caldav client lib I found in the webcal project so that I don't have to start from the scratch and after debugging the code line by line and looking also into the server code, I replaced "text/icalendar" with "text/calendar" and suddenly everything was working as intended. ;-)

I'm currently working on the implementation of Caldav for a school server system used on over 500 schools in Germany. Davical will be the backend and FullCalendar [1] the frontend. So I'm now working on the frontend code logic and so far it's all working great. Thanks for your awesome work on Davical!

Best regards
Matthias

[1] http://arshaw.com/fullcalendar/

Hi namesake :-)

> Yes and no. At the moment I'm using a Caldav client lib I found in the webcal project
Why don't you use davical's libawl?
Is it too complicated?
Or doesn't it fit your needs?

> Davical will be the backend and FullCalendar [1] the frontend.
> So I'm now working on the frontend code logic and so far it's all working
great.
Very interesting approach.
So dumbed-down you're writing a "feed" or extension for fullcalender which
implements the caldav protocol and is able to communicate with davical?
Will it be possible to view multiple (davical-) calendars in one fullcalendar
view?

If you're finished it could become a really nice frontend for davical ;-)
Do you plan to provide a publicly available version of your work?
Or will it only be "internally" available?

regards,
Matthias

<copy />Hi namesake :-)<paste />

> Why don't you use davical's libawl?
> Is it too complicated?
> Or doesn't it fit your needs?
Dunno. I don't like reeventing the wheel so I thought it would be a good start. ;-)

> Very interesting approach.
Yeah... as stated above... no fan of reeventing... ^^

> So dumbed-down you're writing a "feed" or extension for fullcalender which
> implements the caldav protocol and is able to communicate with davical?
FC is just a pure visual frontend for some kind of event source and possible callbacks for different kind of actions (event drag and drop, resizing, clicking, ...).

First part was easy:
I wrote a simple script generating a JSON feed which is added as an event source to FC. FC sends a query with start and end time and I just query the Caldav server.

Now I'm coding the other needed actions:
* Drag an event to another day => Query the server for the event, update its data and send it back.
* Resize an event => same thing
* and so on...

Besides nasty timezone issues it wasn't that hard to implement.

> Will it be possible to view multiple (davical-) calendars in one fullcalendar
> view?
It's planned and the basics shouldn't be too complicated. I've more concerns about porting our current calendar structure (based on users and groups) to Caldav. :|

> If you're finished it could become a really nice frontend for davical ;-)
^^

> Do you plan to provide a publicly available version of your work?
> Or will it only be "internally" available?
At the moment it's only internal work as it's directed to our special needs. I can see if I can convert it to a more general approach (like "FC Caldav Backend") to make it available... and ask my boss. ;-)

<copy />regards,
Matthias<paste />

On Thu, 2010-11-11 at 13:22 +0100, Matthias Althaus wrote:
> <copy />Hi namesake :-)<paste />
>
> > Why don't you use davical's libawl?
> > Is it too complicated?
> > Or doesn't it fit your needs?
> Dunno. I don't like reeventing the wheel so I thought it would be a good start. ;-)

I think he meant the inc/caldav-client-v2.php code which is included
with DAViCal but isn't usually used *by* DAViCal. It's a basic CalDAV
client class that does some server capability discovery, collection
discovery and lightly wraps some requests like PROPFIND and REPORT.


> First part was easy:
> I wrote a simple script generating a JSON feed which is added as an
> event source to FC. FC sends a query with start and end time and I
> just query the Caldav server.
>
> Now I'm coding the other needed actions:
> * Drag an event to another day => Query the server for the event,
> update its data and send it back.
> * Resize an event => same thing
> * and so on...
>
> Besides nasty timezone issues it wasn't that hard to implement.

Something that might make it easier, is that DAViCal supports expanding
the events in a calendar-query REPORT request. This means that you can
request the *expanded* instances of events in a time range and you will
get back all of the instances, localised to UTC.

In javascript it should be relatively easy to then localise the UTC to
the user's actual timezone.


> > Will it be possible to view multiple (davical-) calendars in one fullcalendar
> > view?
> It's planned and the basics shouldn't be too complicated. I've more
> concerns about porting our current calendar structure (based on users
> and groups) to Caldav. :|

I'm happy to chat about it on IRC if you wish. You may want to get onto
#davical on irc.oftc.net where I usually am. The twelve hour time
difference is sometimes a problem but there's usually some overlap with
the time I'm awake.


> > If you're finished it could become a really nice frontend for davical ;-)
> ^^
>
> > Do you plan to provide a publicly available version of your work?
> > Or will it only be "internally" available?
> At the moment it's only internal work as it's directed to our special
> needs. I can see if I can convert it to a more general approach (like
> "FC Caldav Backend") to make it available... and ask my boss. ;-)

It would certainly be nice if you could make something available.

Regards,
Andrew McMillan.

PS. I've had some messages bounced by your mail server due to some spam
checking happening after forwarding and thus rejecting my mail due to
the SPF on my domain. Whoops :-)

--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Building more free and open source software for the World.
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-dev/attachments/20101112/c2fe94e7/attachment.pgp>

Hey,

>I think he meant the inc/caldav-client-v2.php code which is included
Yes and no. I used some code of mir's Webcal:

http://subversion.datanom.net/index.py/webcal/trunk/caldav/

>Something that might make it easier, is that DAViCal supports expanding
>the events in a calendar-query REPORT request.
I haven't dug into the details of what query types are used for what. My problem was the following:

I had the drag and drop action from FC whereof I created an AJAX request like "Take event UID and move it by X days". So I asked Davical for the data of event UID, took the start and end time, modified it by X days and send it back. In the process of adding the offset I had some issues that the timezone offset was automatically computed into the timestamp. But this is something I should get rid off with some code clean up. Sadly I cannot use PHP 5.3 yet which offers some nice new features for DateTime handling. :'(

>The twelve hour time difference is sometimes a problem but there's usually some overlap with the time I'm awake.
I can see if I can get the dust of my IRC client. I was chatting with a US mate with 9 hours diff and we met normally when he was up late and I went just up. ^^

>It would certainly be nice if you could make something available.
Yeah... as written... I'll try to get something out. Have to talk to my boss first, who has his own "timezone" in our company. ;-)

>thus rejecting my mail due to the SPF on my domain. Whoops :-)
Yeah... had the same problem yesterday. I'm forwarding my company mail address to my own mail server. Now the company's server is forwarding the mail while enveloping the original address. My own server checks SPF and BOOM! ... mail rejected. Something I have to tell my boss, too. ^^

Cheers
Matthias

On Fri, 2010-11-12 at 11:29 +0100, Matthias Althaus wrote:
> Hey,
>
> >I think he meant the inc/caldav-client-v2.php code which is included
> Yes and no. I used some code of mir's Webcal:
>
> http://subversion.datanom.net/index.py/webcal/trunk/caldav/
>
> >Something that might make it easier, is that DAViCal supports
> expanding
> >the events in a calendar-query REPORT request.
> I haven't dug into the details of what query types are used for what.

PROPFIND is pretty basic, just returning some requested set of
properties for a single resource, or for every resource in a collection.

REPORT i much more sophisticated, and what it does depends on the type
of XML document you send along with the request. In general the
calendar-query REPORT is used for selecting events from a collection
which match a particular criteria. Inevitably the most popular criteria
is a time-range. The report can also include something to tell the
server to send the response back with the events fully expanded to their
individual instances.

There are examples of these things (request & response) in DAViCal's
regression tests, like:

http://repo.or.cz/w/davical.git/blob/HEAD:/testing/tests/regression-suite/0961-REPORT-public-expanded.test
http://repo.or.cz/w/davical.git/blob/HEAD:/testing/tests/regression-suite/0961-REPORT-public-expanded.result

That expansion process uses the code in davical/inc/RRule-v2.php


> My problem was the following:
>
> I had the drag and drop action from FC whereof I created an AJAX
> request like "Take event UID and move it by X days". So I asked
> Davical for the data of event UID, took the start and end time,
> modified it by X days and send it back. In the process of adding the
> offset I had some issues that the timezone offset was automatically
> computed into the timestamp. But this is something I should get rid
> off with some code clean up. Sadly I cannot use PHP 5.3 yet which
> offers some nice new features for DateTime handling. :'(

I feel your pain.

The PHP DateTime/DateTimeZone classes actually started to work with PHP
5.2, so I use them when they are available, and I have some wrappers for
them which mean I can add support for 5.3 features into if I need it.


> >The twelve hour time difference is sometimes a problem but there's
> usually some overlap with the time I'm awake.
> I can see if I can get the dust of my IRC client. I was chatting with
> a US mate with 9 hours diff and we met normally when he was up late
> and I went just up. ^^

Yep, that's mostly how it works :-)

Cheers,
Andrew.

--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
This fortune was brought to you by the people at Hewlett-Packard.
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-dev/attachments/20101113/b7312a5f/attachment.pgp>

Good Morning! :)

> PROPFIND is pretty basic, just returning some requested set of
> properties for a single resource, or for every resource in a collection.
Ok.


> REPORT i much more sophisticated, and what it does depends on the type
> of XML document you send along with the request. In general the
> calendar-query REPORT is used for selecting events from a collection
> which match a particular criteria. Inevitably the most popular criteria
> is a time-range. The report can also include something to tell the
> server to send the response back with the events fully expanded to their
> individual instances.
>
> That expansion process uses the code in davical/inc/RRule-v2.php
So all the parsing of the repetition rules is done server sided and I'm getting a list of all "real" events? That would mean that I don't have to programm this stuff all over again? That would make me happy! ;-)

> I feel your pain.
>
> The PHP DateTime/DateTimeZone classes actually started to work with PHP
> 5.2, so I use them when they are available, and I have some wrappers for
> them which mean I can add support for 5.3 features into if I need it.
Our server system is based on Lenny so I'm currently stuck at 5.2. :(

Could you share your wrappers or are they even in Davical? :)

Cheers
Matthias

On Mon, 2010-11-15 at 10:16 +0100, Matthias Althaus wrote:
> Good Morning! :)
>
> > PROPFIND is pretty basic, just returning some requested set of
> > properties for a single resource, or for every resource in a collection.
> Ok.
>
>
> > REPORT i much more sophisticated, and what it does depends on the type
> > of XML document you send along with the request. In general the
> > calendar-query REPORT is used for selecting events from a collection
> > which match a particular criteria. Inevitably the most popular criteria
> > is a time-range. The report can also include something to tell the
> > server to send the response back with the events fully expanded to their
> > individual instances.
> >
> > That expansion process uses the code in davical/inc/RRule-v2.php
> So all the parsing of the repetition rules is done server sided and
> I'm getting a list of all "real" events? That would mean that I don't
> have to programm this stuff all over again? That would make me
> happy! ;-)

Exactly. Look at the requests in the regression tests like:

http://repo.or.cz/w/davical.git/blob/HEAD:/testing/tests/regression-suite/0962-REPORT-expanded.test

And the corresponding .result file for DAViCal's response.


> > The PHP DateTime/DateTimeZone classes actually started to work with PHP
> > 5.2, so I use them when they are available, and I have some wrappers for
> > them which mean I can add support for 5.3 features into if I need it.
> Our server system is based on Lenny so I'm currently stuck at 5.2. :(
>
> Could you share your wrappers or are they even in Davical? :)

Of course :-)

http://repo.or.cz/w/davical.git/blob/HEAD:/inc/RRule-v2.php

Look at the RepeatRuleDateTimeZone and RepeatRuleDateTime clases - and
anything else you wish, of course. Sometimes people seem to be
challenged by the way RepeatRule itself works, but I would welcome bug
reports, especially with patches :-)

Cheers,
Andrew.

--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
The future isn't what it used to be. (It never was.)
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-dev/attachments/20101115/4c07693a/attachment.pgp>

> > > REPORT i much more sophisticated, and what it does depends on the type
> > > of XML document you send along with the request. In general the
> > > calendar-query REPORT is used for selecting events from a collection
> > > which match a particular criteria. Inevitably the most popular criteria
> > > is a time-range. The report can also include something to tell the
> > > server to send the response back with the events fully expanded to their
> > > individual instances.
> > >
> > > That expansion process uses the code in davical/inc/RRule-v2.php
> > So all the parsing of the repetition rules is done server sided and
> > I'm getting a list of all "real" events? That would mean that I don't
> > have to programm this stuff all over again? That would make me
> > happy! ;-)
>
> Exactly. Look at the requests in the regression tests like:
>
> http://repo.or.cz/w/davical.git/blob/HEAD:/testing/tests/regression-suite/0962-REPORT-expanded.test
>
> And the corresponding .result file for DAViCal's response.
Sweeeeet! :)

So if this is a Caldav standard every Caldav server should (read MUST) support it?

> > > The PHP DateTime/DateTimeZone classes actually started to work with PHP
> > > 5.2, so I use them when they are available, and I have some wrappers for
> > > them which mean I can add support for 5.3 features into if I need it.
> > Our server system is based on Lenny so I'm currently stuck at 5.2. :(
> >
> > Could you share your wrappers or are they even in Davical? :)
>
> Of course :-)
>
> http://repo.or.cz/w/davical.git/blob/HEAD:/inc/RRule-v2.php
>
> Look at the RepeatRuleDateTimeZone and RepeatRuleDateTime clases - and
> anything else you wish, of course. Sometimes people seem to be
> challenged by the way RepeatRule itself works, but I would welcome bug
> reports, especially with patches :-)
Sweeeeeeet again! I'll take a look at what I finally need and give you feedback. I started a clean "client" now and still have some problems getting everything to work as intended, but that's just a matter of time.

Cheers again
Matthias

On Mon, 2010-11-15 at 10:50 +0100, Matthias Althaus wrote:
> > > > REPORT i much more sophisticated, and what it does depends on the type
> > > > of XML document you send along with the request. In general the
> > > > calendar-query REPORT is used for selecting events from a collection
> > > > which match a particular criteria. Inevitably the most popular criteria
> > > > is a time-range. The report can also include something to tell the
> > > > server to send the response back with the events fully expanded to their
> > > > individual instances.
> > > >
> > > > That expansion process uses the code in davical/inc/RRule-v2.php
> > > So all the parsing of the repetition rules is done server sided and
> > > I'm getting a list of all "real" events? That would mean that I don't
> > > have to programm this stuff all over again? That would make me
> > > happy! ;-)
> >
> > Exactly. Look at the requests in the regression tests like:
> >
> > http://repo.or.cz/w/davical.git/blob/HEAD:/testing/tests/regression-suite/0962-REPORT-expanded.test
> >
> > And the corresponding .result file for DAViCal's response.
> Sweeeeet! :)
>
> So if this is a Caldav standard every Caldav server should (read MUST) support it?

Well, yes, but +/- bugs... and it's likely not a well-tested piece of
code anywhere because very few clients use the functionality. I know
there are some minor bugs in this in 0.9.9.3 which are fixed in HEAD,
also.


> > Look at the RepeatRuleDateTimeZone and RepeatRuleDateTime clases - and
> > anything else you wish, of course. Sometimes people seem to be
> > challenged by the way RepeatRule itself works, but I would welcome bug
> > reports, especially with patches :-)
> Sweeeeeeet again! I'll take a look at what I finally need and give you
> feedback. I started a clean "client" now and still have some problems
> getting everything to work as intended, but that's just a matter of
> time.

Great :-)

Cheers,
Andrew.

--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Audacity, and again, audacity, and always audacity.
-- G. J. Danton

------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-dev/attachments/20101116/0d941254/attachment.pgp>

> > >
> > > Exactly. Look at the requests in the regression tests like:
> > >
> > > http://repo.or.cz/w/davical.git/blob/HEAD:/testing/tests/regression-suite/0962-REPORT-expanded.test
> > >
> > > And the corresponding .result file for DAViCal's response.
> > Sweeeeet! :)
> >
> > So if this is a Caldav standard every Caldav server should (read MUST) support it?
>
> Well, yes, but +/- bugs... and it's likely not a well-tested piece of
> code anywhere because very few clients use the functionality. I know
> there are some minor bugs in this in 0.9.9.3 which are fixed in HEAD,
> also.
So should I prefer to not rely on Caldav servers supporting it in general and compute the active dates on my client side?

Cheers
Matthias

On Tue, 2010-11-16 at 10:07 +0100, Matthias Althaus wrote:
> > > >
> > > > Exactly. Look at the requests in the regression tests like:
> > > >
> > > > http://repo.or.cz/w/davical.git/blob/HEAD:/testing/tests/regression-suite/0962-REPORT-expanded.test
> > > >
> > > > And the corresponding .result file for DAViCal's response.
> > > Sweeeeet! :)
> > >
> > > So if this is a Caldav standard every Caldav server should (read MUST) support it?
> >
> > Well, yes, but +/- bugs... and it's likely not a well-tested piece of
> > code anywhere because very few clients use the functionality. I know
> > there are some minor bugs in this in 0.9.9.3 which are fixed in HEAD,
> > also.
> So should I prefer to not rely on Caldav servers supporting it in
> general and compute the active dates on my client side?

Ideally you should not rely on caldav servers supporting it and
blacklist the ones that don't :-)

Of course I can say that because I know DAViCal does...

Perhaps you would get a different answer from the developer of a server
that did not support it!

Seriously though: it's mandated as 'MUST' and even when DAViCal didn't
support it I know that finding a client that wanted me to do so would
(OK: did :-) make a difference.

Cheers,
Andrew.

--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Marriage causes dating problems.
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-dev/attachments/20101116/976a89b7/attachment.pgp>

> > > Well, yes, but +/- bugs... and it's likely not a well-tested piece of
> > > code anywhere because very few clients use the functionality. I know
> > > there are some minor bugs in this in 0.9.9.3 which are fixed in HEAD,
> > > also.
> > So should I prefer to not rely on Caldav servers supporting it in
> > general and compute the active dates on my client side?
>
> Ideally you should not rely on caldav servers supporting it and
> blacklist the ones that don't :-)
>
> Of course I can say that because I know DAViCal does...
>
> Perhaps you would get a different answer from the developer of a server
> that did not support it!
>
> Seriously though: it's mandated as 'MUST' and even when DAViCal didn't
> support it I know that finding a client that wanted me to do so would
> (OK: did :-) make a difference.
Ok... so I'll first try it with server side expanding and then see what will happen. For us using Davical as the Caldav server it should work. ;-)

Cheers
Matthias