Subject: [Ietf-caldav] software
From: Wei Li <[email-masked]>
To: caldav DevList <[email-masked]>
Date: Tue, 21 Jun 2005 12:42:12 -0400
List-Id: Discussions on Calendar Access protocol based on WebDAV <ietf-caldav.osafoundation.org>

Hi, all,

Where can I find this caldav implementation or the application. I am 
trying to install one web calender, any suggestion?

Thanks a lot

Wei

From: "Chris Bryant" <[email-masked]>
To: "caldav DevList" <[email-masked]>
Subject: Re: [Ietf-caldav] draft-dusseault-caldav-06.txt
Date: Fri, 17 Jun 2005 15:40:57 -0400
Organization: USA.NET
Z-USANET-MsgId: XID767JFqTO80317X38

Hi Cyrus,

----- Original Message ----- 
From: "Cyrus Daboo" <[email-masked]>
To: "Chris Bryant" <[email-masked]>; "caldav DevList" 
<[email-masked]>
Sent: Friday, June 17, 2005 10:45 AM
Subject: Re: [Ietf-caldav] draft-dusseault-caldav-06.txt

>
> Believe it or not, iCalendar does not actually require the UID parameter 
> on components (and in the case of VTIMEZONE it is not allowed at all, 
> though one could probably key off TZID instead). e.g. the VEVENT UID falls 
> under the:
>
>                ; the following are optional,
>                ; but MUST NOT occur more than once
>
> section. Thus CalDAV cannot rely on UIDs for resource names. Of course we 
> could stipulate that any components stored MUST have a UID. At the very 
> least we need to explain how to handle components without a UID (which we 
> probably need to do for VTIMEZONE anyway).

In RFC 2445, paragraph 4.8.4 Unique Identifier, under the Conformance 
paragraph, it states 'The property MUST be specified in the "VEVENT", 
"VTODO", "VJOURNAL" or "VFREEBUSY" calendar components.'  Looking at the 
iTIP spec, all messages, other than VFREEBUSY PUBLISH messages, require a 
UID.  So, combining the two specs, it seems that the only exception to 
requiring a UID would be if we have VFREEBUSY resources in a collection.  It 
appears that CalDAV intends to support these, but I can't see why.  It seems 
that if a client needs to store general VFREEBUSY  information on the server 
that is separate from the VEVENT data also stored on the server, then the 
spec could insist that the VFREEBUSY data should also have a UID.

As far as VTIMEZONEs, I thought the last CalDAV draft completely removed the 
idea of treating VTIMEZONEs as separate resources in their own collection.

>
> Note also that I think we may be relaxing the 'all components with the 
> same UID in one resource' rule for the special collections defined in the 
> schedule draft. That is because with iTIP, there can be multiple responses 
> (from each attendee) to a single request, and each of those would have the 
> same UID, but it would be better to keep all those responses as separate 
> resources for the purposes of processing.

I agree with needing to be able to process responses as separate resources, 
but once the responses are processed, they should be able to be folded into 
the one larger resource for the UID.  Although I haven't read through the 
caldav-sched draft yet, it seems that responses in the special Inbox 
collection could have a different URL scheme to handle this issue.

Thanks,
Chris 

Date: Fri, 17 Jun 2005 10:45:10 -0400
From: Cyrus Daboo <[email-masked]>
To: Chris Bryant <[email-masked]>, caldav DevList <[email-masked]>
Subject: Re: [Ietf-caldav] draft-dusseault-caldav-06.txt

Hi Chris,

--On June 17, 2005 10:13:38 AM -0400 Chris Bryant 
<[email-masked]> wrote:

> Is there some reason why CalDAV does not simply require that the name of
> a resource match the UID?  Since the current version of the spec does not
> allow the return of the Location header to allow the server to rename a
> resource URL after creation, it seems that the calendar clients will need
> to come up with some arbitrary name for the URL, hope that it is unique,
> and remember it for subsequent use.  It seems to me the that UID would
> suit this purpose fine; the UID is already required to be unique within a
> collection and all information tied to a single UID must be in a single
> must be in the same resource.  The UID is not end-user friendly, but
> end-users will not have any reason to see the URL anyways.  The UID would
> need to be url-encoded, but the rules for that are pretty clear.
>
> If this approach were used, I think the use of the .ics filename
> extension on the URL would need to either be removed completely, or the
> spec would need to say that the URL is actually the UID + ".ics".

Believe it or not, iCalendar does not actually require the UID parameter on 
components (and in the case of VTIMEZONE it is not allowed at all, though 
one could probably key off TZID instead). e.g. the VEVENT UID falls under 
the:

                ; the following are optional,
                ; but MUST NOT occur more than once

section. Thus CalDAV cannot rely on UIDs for resource names. Of course we 
could stipulate that any components stored MUST have a UID. At the very 
least we need to explain how to handle components without a UID (which we 
probably need to do for VTIMEZONE anyway).

Note also that I think we may be relaxing the 'all components with the same 
UID in one resource' rule for the special collections defined in the 
schedule draft. That is because with iTIP, there can be multiple responses 
(from each attendee) to a single request, and each of those would have the 
same UID, but it would be better to keep all those responses as separate 
resources for the purposes of processing.

-- 
Cyrus Daboo

From: "Chris Bryant" <[email-masked]>
To: "caldav DevList" <[email-masked]>
Subject: Re: [Ietf-caldav] draft-dusseault-caldav-06.txt
Date: Fri, 17 Jun 2005 10:13:38 -0400
Organization: USA.NET
Z-USANET-MsgId: XID573JFqoNn0158X31

Is there some reason why CalDAV does not simply require that the name of a 
resource match the UID?  Since the current version of the spec does not 
allow the return of the Location header to allow the server to rename a 
resource URL after creation, it seems that the calendar clients will need to 
come up with some arbitrary name for the URL, hope that it is unique, and 
remember it for subsequent use.  It seems to me the that UID would suit this 
purpose fine; the UID is already required to be unique within a collection 
and all information tied to a single UID must be in a single must be in the 
same resource.  The UID is not end-user friendly, but end-users will not 
have any reason to see the URL anyways.  The UID would need to be 
url-encoded, but the rules for that are pretty clear.

If this approach were used, I think the use of the .ics filename extension 
on the URL would need to either be removed completely, or the spec would 
need to say that the URL is actually the UID + ".ics".

Thanks,

Chris

Date: Tue, 14 Jun 2005 10:09:13 -0400
From: Simon Vaillancourt <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-caldav] looking for open source CalDAV client

Hello,
    The CalConnectCalDAVTest script used during the InterOp has been 
posted in there: http://www.calconnect.org/ioptesting.html . Take note 
that there are many tough edges but it has proven very useful for server 
implementors.

Enjoy!

--Simon

Simon Vaillancourt wrote:

> Hello,
>   The tool in question is just a bash script calling davtool and wget 
> to go over the interop's test cases, the only validation done is of 
> the returned HTTP code, but you get a pretty good report on what was 
> sent/received. I should be able to make it available next week and let 
> you know.
>
> Thanks
> --Simon
>
> Brian Moseley wrote:
>
>> Cyrus Daboo wrote:
>>
>>> One of the participants at last week's Calconnect CalDAV interop had 
>>> a davtool (<http://davtool.sourceforge.net/>) based scripting 
>>> mechanism for running through all the test cases in the interop. 
>>> That seemed to work very well and found several bugs in server 
>>> implementations, including mine! I believe a process is in hand for 
>>> making that tool publicly available.
>>
>>
>>
>> neat. how is it different from litmus?
>> _______________________________________________
>> Ietf-caldav mailing list -- [email-masked]
>> See http://ietf.webdav.org/caldav/ for more CalDAV resources
>> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
>
>
>
> _______________________________________________
> Ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

From: Grant Baillie <[email-masked]>
Subject: Re: [Ietf-caldav] looking for open source CalDAV client
Date: Mon, 13 Jun 2005 14:02:21 -0700
To: Brian Moseley <[email-masked]>
Cc: [email-masked]

On Jun 8, 2005, at 1:51 PM, Brian Moseley wrote:

> Kervin L. Pierre wrote:
>
>
>> Funny, I've been waiting on a your server to start
>> with my client library :)
>>
>
> heh! one of us is going to have to bite the bullet. i guess that  
> will be me :)
>
>
>> I am looking too extend the Neon WebDAV library.
>> Having a plain C CalDAV library would mean that
>> Perl, Python or any language with C language
>> bindings can use it.  Neon is cross-platform
>> ( including Windows ) and LGPL.
>>
>
> that sounds cool. there's already a perl wrapper for neon  
> (HTTP::WebDAV i think it's called). i'd like to see a similar php  
> extension.
>
>
>> Unfortunately Perl doesn't do me much good since
>> my app is a C++ library.  Same goes for Python
>> which would be needed soon for Chandler (?)
>>
>
> Grant is out of the office for a few days, but when he gets back,  
> i'm sure he'll tell you about zanshin and twisted and all sorts of  
> python business. i don't have my head wrapped around most of it.

Being back now, I can follow up. zanshin is the high-level http/ 
webdav/caldav client library I'm currently working on, as originally  
conceived by Lisa Dusseault. Here "high-level" means dealing more at  
the level of resources instead of requests and responses; the library  
takes care (or is supposed to take care) of details like caching,  
failed/dropped connections, etc. It is written in Python, and uses  
the twisted networking framework (<http://twistedmatrix.com>), since  
asynchronicity is something we'll need in Chandler.

Right now, there's no CalDAV functionality, and even the WebDAV stuff  
is pretty rudimentary. It is at least vaguely usable (the latest and  
greatest Chandler is using it for WebDAV-based sharing). It's  
browsable in our svn repository at <http://svn.osafoundation.org/ 
zanshin/trunk/>: comments/suggestions/constructive criticisms are  
welcome.

--Grant
Grant Baillie
Open Source Applications Foundation
http://www.osafoundation.org

Date: Mon, 13 Jun 2005 11:41:57 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: ietf-caldav list <[email-masked]>
Subject: [Ietf-caldav] Reminder -- Questionnaire on Implementation of Timezones -- Calconnect and Calsify
Reply-To: [email-masked]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<pre wrap="">Dear Folks,

This is a followup reminder to my e-mail of May 24th requesting assistance in responding to a Calconnect questionnaire on Timezones.  Our original target date for responses was June 10th. We're received several responses but hope that with a little more time others will be able to help us.  If you've not responded but have a calendaring implementation, we would appreciate it very much if you could take a few minutes to respond to our questionnaire.

We've extended the target date another week to Monday, June 20th -- and so you don't have to rummage around and find my previous e-mail, the questionniare (which is in e-mail format so you can fill it out and e-mail it back) is included below.

Thank you very much for your help.

Dave Thewlis
---
<b>Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium</b>
+1 707 840 9391 (voice) &middot; +1 707 498 2238 (mobile)
<a href="http://www.calconnect.org%3E">http://www.calconnect.org</a> &middot; <a
 href="mailto:[email-masked]">[email-masked]</a>

------------------------------------------------------------------------------------------
Questionnaire on Timezones in iCalendar

Introduction:

This questionnaire is being used to determine support for iCalendar
(RFC2445) timezone support. The specific sections in RFC2445 that
are being queried are:

4.6.5       Time Zone Component
4.8.2.4     Date/Time Start
4.8.3       Time Zone Component Properties
     ( and sub-sections )
4.8.5.3     Recurrence Date/Times
4.8.5.4     Recurrence Rule
4.8.7.3     Last Modified
4.8.8.1     Non-standard Properties

These may involve reference to other sections.

How to answer:

Please copy the text from the '-------' divider below to the end of
this message into a new message and address it to:

    <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;mailto:[email-masked]&gt;</a>

To fill it out:

For 'y/n/o':

    'y' means yes
    'n' means no
    'o' means other or not applicable

    Delete two letters to leave the one for your answer.
    If you have specific comments you can add about your answers,
    please do so at the end and reference the question number to which
    the comment applies.
    
For _____________________: enter text for the answer.

-------

Product Details:

P1:		Product/Implementation Name:
        
        _____________________

Components supported:

                                   Consume         Produce
Q1:     VTIMEZONE                   y/n/o           y/n/o
Q1.1:   STANDARD                    y/n/o           y/n/o
Q1.2:   DAYLIGHT                    y/n/o           y/n/o

Properties supported:
                                
        In VTIMEZONE
                                   Consume         Produce
Q2.1:   TZID                        y/n/o           y/n/o
Q2.2:   LAST-MODIFIED               y/n/o           y/n/o
Q2.3:   TZURL                       y/n/o           y/n/o
Q2.4:   XPROP                       y/n/o           y/n/o

        In STANDARD
                                   Consume         Produce
Q3.1:   DTSTART                     y/n/o           y/n/o
Q3.2:   TZOFFSETTO                  y/n/o           y/n/o
Q3.3:   TZOFFSETFROM                y/n/o           y/n/o
Q3.4:   COMMENT                     y/n/o           y/n/o
Q3.5:   RDATE                       y/n/o           y/n/o
Q3.6:   RRULE                       y/n/o           y/n/o
Q3.7:   TZNAME                      y/n/o           y/n/o
Q3.8:   XPROP                       y/n/o           y/n/o

        In DAYLIGHT
                                   Consume         Produce
Q4.1:   DTSTART                     y/n/o           y/n/o
Q4.2:   TZOFFSETTO                  y/n/o           y/n/o
Q4.3:   TZOFFSETFROM                y/n/o           y/n/o
Q4.4:   COMMENT                     y/n/o           y/n/o
Q4.5:   RDATE                       y/n/o           y/n/o
Q4.6:   RRULE                       y/n/o           y/n/o
Q4.7:   TZNAME                      y/n/o           y/n/o
Q4.8:   XPROP                       y/n/o           y/n/o

General:
    
Q5:  Do you always send DATE-TIME
     values with a timezone?         y/n/o

Q6:  Do you always send DATE-TIME
     values in UTC or floating?      y/n/o

Q7:  Do you provide a standard
     set of timezones built-in
     to your product?                y/n/o

     if yes to Q7, then
     {
Q8:     Where did you get your
        timezone definitions?
        
        _____________________
        
Q9:     How many timezone
        definitions do you have?
        
        _____________________
        
Q10:    Do you have a special
        naming scheme for TZIDs,
        and if so what is it?
        
        _____________________
        
Q11:    Do you provide a mechanism
        for updating built-in
        timezones?                  y/n/o
        
        if yes to Q11, then
        {
Q12:        Do you adjust future
            times to account for
            timezone definition
            changes?                y/n/o
        }

     }
    
Q13: Do you accept and use
     timezone definitions from
     imported iCalendar data?       y/n/o

     if yes to Q13, then
     {   
Q14:    Do you attempt to merge
        timezone definitions with the
        same TZID when importing
        iCalendar data?             y/n/o
     }
    
Q15: When exporting timezones in
     iCalendar data (either to a file
     or via iTIP) do you send the entire
     timezone definition or just the
     set of dates needed for coverage
     of the event?

     _____________________
    
Q16: Would you use timezone
     definitions from a standard
     timezone registry if one
     were created?                   y/n/o
    
Q17: What problems would be
     involved in changing a
     timezone definition if DST
     was changed at some point
     in the future?
    
     _____________________

C1:  Comments on specific answers (include Q number for cross-reference
     to original question):

     _____________________

C2:  Comments on the format and ease of use of this questionnaire:

     _____________________

C3:  Are there any additional questions we should be asking, and if
     so what are they?

     _____________________

</pre>
<br>
<div class="moz-signature"><br>
</div>
</body>
</html>

Date: Thu, 09 Jun 2005 13:18:16 -0400
From: Simon Vaillancourt <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-caldav] looking for open source CalDAV client

Hello,
   The tool in question is just a bash script calling davtool and wget 
to go over the interop's test cases, the only validation done is of the 
returned HTTP code, but you get a pretty good report on what was 
sent/received. I should be able to make it available next week and let 
you know.

Thanks
--Simon

Brian Moseley wrote:

> Cyrus Daboo wrote:
>
>> One of the participants at last week's Calconnect CalDAV interop had 
>> a davtool (<http://davtool.sourceforge.net/>) based scripting 
>> mechanism for running through all the test cases in the interop. That 
>> seemed to work very well and found several bugs in server 
>> implementations, including mine! I believe a process is in hand for 
>> making that tool publicly available.
>
>
> neat. how is it different from litmus?
> _______________________________________________
> Ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Date: Thu, 9 Jun 2005 08:55:48 +0100
From: Joe Orton <[email-masked]>
To: BrianBoy <[email-masked]>
Subject: Re: [Ietf-caldav] Libneon and Simple Client to test CALDAV
Mail-Followup-To: BrianBoy <[email-masked]>, [email-masked]
Cc: [email-masked]

On Wed, Jun 08, 2005 at 06:45:19PM -0700, BrianBoy wrote:
> I did some testing with libneon , it is a very good starting point , new DAV
> headers and methods can be added without much hassle and code change. Also
> the good thing about libneon is it supports SSL and also various
> authentication methods Digest/Negotiate etc.

FWIW, I'd welcome the contribution of CalDAV test cases to litmus, it's
pretty easy to add tests there.

Regards,

joe

Date: Wed, 08 Jun 2005 18:45:19 -0700
From: BrianBoy <[email-masked]>
To: <[email-masked]>
Subject: [Ietf-caldav] Libneon and Simple Client to test CALDAV

I did some testing with libneon , it is a very good starting point , new DAV
headers and methods can be added without much hassle and code change. Also
the good thing about libneon is it supports SSL and also various
authentication methods Digest/Negotiate etc.

Brian

>Message: 1
>Date: Wed, 08 Jun 2005 12:29:15 -0700
>From: Brian Moseley <[email-masked]>
>Subject: [Ietf-caldav] looking for open source CalDAV client
>To: [email-masked]
>Message-ID: <[email-masked]>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed

>any open source CalDAV client projects going on out there?

>i'm looking for a simple command line tool to help with developing and
>testing our server. unfortunately neither curl nor lwp-request seem to
>support arbitrary HTTP methods, so they won't be immediately useful.

>the perldav project (<http://www.webdav.org/perldav/>) doesn't seem to
>have been active in years, but it looks to have a good base to build on.
>i've contacted the author but haven't heard back yet.

>if nobody has anything more substantial, i'll probably hack together
>something based on perldav. if anyone's interested in helping out, let
>me know.
>
>thanks!

Date: Wed, 08 Jun 2005 14:12:27 -0700
From: Brian Moseley <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-caldav] looking for open source CalDAV client

Cyrus Daboo wrote:

> Forget that - just found it. Obviously davtool and litmus are different 
> entities altogether. davtool seems to operate at a much lower level 
> (e.g. its basically an http test tool that allows you to choose the 
> method).

yeah, looking at it further, you could probably build litmus using davtool.

unfortunately, it doesn't build for me on os x 10.4. the README is for a 
different project altogether, and the source references a bundled expat 
that doesn't actually exist. shrug.

Date: Wed, 08 Jun 2005 17:02:06 -0400
From: Cyrus Daboo <[email-masked]>
To: Brian Moseley <[email-masked]>, [email-masked]
Subject: Re: [Ietf-caldav] looking for open source CalDAV client

Hi Cyrus,

--On June 8, 2005 4:57:57 PM -0400 Cyrus Daboo <[email-masked]> wrote:

>> neat. how is it different from litmus?
>
> Don't know - what is litmus?

Forget that - just found it. Obviously davtool and litmus are different 
entities altogether. davtool seems to operate at a much lower level (e.g. 
its basically an http test tool that allows you to choose the method).

-- 
Cyrus Daboo

Date: Wed, 08 Jun 2005 13:58:40 -0700
From: Lisa Dusseault <[email-masked]>
To: "Kervin L. Pierre" <[email-masked]>
Subject: Re: [Ietf-caldav] looking for open source CalDAV client
Cc: Morgen Sagen <[email-masked]>, [email-masked]

Kervin, would you be interested in access to WebDAV servers to test at 
least the WebDAV part of the functionality?  I can give you an account 
on ietf.webdav.org, which is a Xythos WebDAV server and supports the 
MKTICKET stuff that BCM is currently working on (for that matter you can 
get a free www.sharemation.com account which is the same software 
line).  Email me privately with account name and password choices.

I believe OSAF also has a test server running mod_dav -- I can look into 
whether that's still up and available.

Lisa

Kervin L. Pierre wrote:

> Hello Brian,
>
> Brian Moseley wrote:
>
>> any open source CalDAV client projects going on out there?
>>
>> i'm looking for a simple command line tool to help with developing 
>> and testing our server. unfortunately neither curl nor lwp-request 
>> seem to 
>
>
> Funny, I've been waiting on a your server to start
> with my client library :)
>
>> the perldav project (<http://www.webdav.org/perldav/>) doesn't seem 
>> to have been active in years, but it looks to have a good base to 
>> build on. i've contacted the author but haven't heard back yet.
>>
>
> I am looking too extend the Neon WebDAV library.
> Having a plain C CalDAV library would mean that
> Perl, Python or any language with C language
> bindings can use it.  Neon is cross-platform
> ( including Windows ) and LGPL.
>
> Unfortunately Perl doesn't do me much good since
> my app is a C++ library.  Same goes for Python
> which would be needed soon for Chandler (?)
>
> Maybe there can be a 'libCosmo' or 'libCalDAV'
> sub-project to Cosmo that aims to produce
> reference ( or simply initial ) implementations
> of CalDAV routines in C and Java?
>
> Regards,
> Kervin
> _______________________________________________
> Ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
>

Date: Wed, 08 Jun 2005 16:57:57 -0400
From: Cyrus Daboo <[email-masked]>
To: Brian Moseley <[email-masked]>, [email-masked]
Subject: Re: [Ietf-caldav] looking for open source CalDAV client

Hi Brian,

--On June 8, 2005 1:50:57 PM -0700 Brian Moseley <[email-masked]> 
wrote:

>> One of the participants at last week's Calconnect CalDAV interop had a
>> davtool (<http://davtool.sourceforge.net/>) based scripting mechanism
>> for running through all the test cases in the interop. That seemed to
>> work very well and found several bugs in server implementations,
>> including mine! I believe a process is in hand for making that tool
>> publicly available.
>
> neat. how is it different from litmus?

Don't know - what is litmus?

-- 
Cyrus Daboo

Date: Wed, 08 Jun 2005 13:51:22 -0700
From: Brian Moseley <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-caldav] looking for open source CalDAV client

Kervin L. Pierre wrote:

> Funny, I've been waiting on a your server to start
> with my client library :)

heh! one of us is going to have to bite the bullet. i guess that will be 
me :)

> I am looking too extend the Neon WebDAV library.
> Having a plain C CalDAV library would mean that
> Perl, Python or any language with C language
> bindings can use it.  Neon is cross-platform
> ( including Windows ) and LGPL.

that sounds cool. there's already a perl wrapper for neon (HTTP::WebDAV 
i think it's called). i'd like to see a similar php extension.

> Unfortunately Perl doesn't do me much good since
> my app is a C++ library.  Same goes for Python
> which would be needed soon for Chandler (?)

Grant is out of the office for a few days, but when he gets back, i'm 
sure he'll tell you about zanshin and twisted and all sorts of python 
business. i don't have my head wrapped around most of it.

> Maybe there can be a 'libCosmo' or 'libCalDAV'
> sub-project to Cosmo that aims to produce
> reference ( or simply initial ) implementations
> of CalDAV routines in C and Java?

once we fire up our Scooby project (a CalDAV-based web calendar), we 
will definitely be working towards a Java client library. i don't think 
you'll see OSAF producing a C library anytime soon tho, so i'm happy to 
hear that you're still motivated to work on your stuff :)

Date: Wed, 08 Jun 2005 13:50:57 -0700
From: Brian Moseley <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-caldav] looking for open source CalDAV client

Cyrus Daboo wrote:

> One of the participants at last week's Calconnect CalDAV interop had a 
> davtool (<http://davtool.sourceforge.net/>) based scripting mechanism 
> for running through all the test cases in the interop. That seemed to 
> work very well and found several bugs in server implementations, 
> including mine! I believe a process is in hand for making that tool 
> publicly available.

neat. how is it different from litmus?

Date: Wed, 08 Jun 2005 16:48:48 -0400
From: Cyrus Daboo <[email-masked]>
To: Brian Moseley <[email-masked]>, [email-masked]
Subject: Re: [Ietf-caldav] looking for open source CalDAV client

Hi Brian,

--On June 8, 2005 12:29:15 PM -0700 Brian Moseley <[email-masked]> 
wrote:

> any open source CalDAV client projects going on out there?
>
> i'm looking for a simple command line tool to help with developing and
> testing our server. unfortunately neither curl nor lwp-request seem to
> support arbitrary HTTP methods, so they won't be immediately useful.
>
> the perldav project (<http://www.webdav.org/perldav/>) doesn't seem to
> have been active in years, but it looks to have a good base to build on.
> i've contacted the author but haven't heard back yet.
>
> if nobody has anything more substantial, i'll probably hack together
> something based on perldav. if anyone's interested in helping out, let me
> know.

One of the participants at last week's Calconnect CalDAV interop had a 
davtool (<http://davtool.sourceforge.net/>) based scripting mechanism for 
running through all the test cases in the interop. That seemed to work very 
well and found several bugs in server implementations, including mine! I 
believe a process is in hand for making that tool publicly available.

-- 
Cyrus Daboo

Date: Wed, 08 Jun 2005 16:25:08 -0400
From: "Kervin L. Pierre" <[email-masked]>
To: Brian Moseley <[email-masked]>
Subject: Re: [Ietf-caldav] looking for open source CalDAV client
Cc: [email-masked]

Hello Brian,

Brian Moseley wrote:
> any open source CalDAV client projects going on out there?
> 
> i'm looking for a simple command line tool to help with developing and 
> testing our server. unfortunately neither curl nor lwp-request seem to 

Funny, I've been waiting on a your server to start
with my client library :)

> the perldav project (<http://www.webdav.org/perldav/>) doesn't seem to 
> have been active in years, but it looks to have a good base to build on. 
> i've contacted the author but haven't heard back yet.
> 

I am looking too extend the Neon WebDAV library.
Having a plain C CalDAV library would mean that
Perl, Python or any language with C language
bindings can use it.  Neon is cross-platform
( including Windows ) and LGPL.

Unfortunately Perl doesn't do me much good since
my app is a C++ library.  Same goes for Python
which would be needed soon for Chandler (?)

Maybe there can be a 'libCosmo' or 'libCalDAV'
sub-project to Cosmo that aims to produce
reference ( or simply initial ) implementations
of CalDAV routines in C and Java?

Regards,
Kervin

Date: Wed, 08 Jun 2005 12:29:15 -0700
From: Brian Moseley <[email-masked]>
To: [email-masked]
Subject: [Ietf-caldav] looking for open source CalDAV client

any open source CalDAV client projects going on out there?

i'm looking for a simple command line tool to help with developing and 
testing our server. unfortunately neither curl nor lwp-request seem to 
support arbitrary HTTP methods, so they won't be immediately useful.

the perldav project (<http://www.webdav.org/perldav/>) doesn't seem to 
have been active in years, but it looks to have a good base to build on. 
i've contacted the author but haven't heard back yet.

if nobody has anything more substantial, i'll probably hack together 
something based on perldav. if anyone's interested in helping out, let 
me know.

thanks!