Mailing List Archive

CardDAV once again...
Hi,

now that iOS4 for iPhone is released I really couldn't resist to ask
here once again about the status of the CardDAV implementation in DAViCal?

I know there have been made some first preparations to support CardDAV
in future in DAViCal. But now that with iOS4 the iPhone&Co support
CardDAV as a client it would IMHO perfectly make sense to push that a
little further to get something workable ASAP ;)

So any news on that topic?

regards,
jens
--
Jens Langner, Dresden/Germany
http://www.jens-langner.de/
CardDAV once again... [ In reply to ]
On Tue, 2010-06-22 at 15:49 +0200, Jens Langner wrote:
> Hi,
>
> now that iOS4 for iPhone is released I really couldn't resist to ask
> here once again about the status of the CardDAV implementation in DAViCal?
>
> I know there have been made some first preparations to support CardDAV
> in future in DAViCal. But now that with iOS4 the iPhone&Co support
> CardDAV as a client it would IMHO perfectly make sense to push that a
> little further to get something workable ASAP ;)
>
> So any news on that topic?

I knew someone would be asking... :-)

I'm working on it right now. I gave the iphone to my wife when I
upgraded to an Android and I'm expecting her home this Friday, so I
should be able to borrow it back this weekend for testing before I
release it.

It doesn't look too far off at this point running against OS 10.6 on the
Macbook, but completely different teams actually implement the two
clients, so there could be notable differences.

Cheers,
Andrew.

--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Don't engineer in a crisis. -- Vint Cerf speaking on IPv6
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20100623/e2714af2/attachment.pgp>
-------------- next part --------------
CardDAV once again... [ In reply to ]
Hi Andrew,

Am 22.06.10 23:37, schrieb Andrew McMillan:

>> now that iOS4 for iPhone is released I really couldn't resist to ask
>> here once again about the status of the CardDAV implementation in DAViCal?
>>
>> I know there have been made some first preparations to support CardDAV
>> in future in DAViCal. But now that with iOS4 the iPhone&Co support
>> CardDAV as a client it would IMHO perfectly make sense to push that a
>> little further to get something workable ASAP ;)
>>
>> So any news on that topic?
>
> I knew someone would be asking... :-)

I even wondered myself why nobody asked already on the list ;)

> I'm working on it right now. I gave the iphone to my wife when I
> upgraded to an Android and I'm expecting her home this Friday, so I
> should be able to borrow it back this weekend for testing before I
> release it.
>
> It doesn't look too far off at this point running against OS 10.6 on the
> Macbook, but completely different teams actually implement the two
> clients, so there could be notable differences.

Wow, this sounds promising. Are these changes already in your public
source code repository (http://repo.or.cz/w/davical.git) so that I can
test them myself on my own server and probably give some direct feedback
to you - even before friday? ;)

What might be the current known cultrips still in this code? And does
the setup for the CardDAV part require any special
actions/considerations or will it work out-of-the-box when I checkout
the repository and run the normal installation?

regards,
jens
--
Jens Langner, Dresden/Germany
http://www.jens-langner.de/
CardDAV once again... [ In reply to ]
On Wed, 2010-06-23 at 08:05 +0200, Jens Langner wrote:
>
> Wow, this sounds promising. Are these changes already in your public
> source code repository (http://repo.or.cz/w/davical.git) so that I can
> test them myself on my own server and probably give some direct feedback
> to you - even before friday? ;)

It is now, including a change or two to AWL, which you'd also need to
fetch from http://repo.or.cz/w/awl.git . It's working with Evolution's
WebDAV Addressbook plugin now, as well.


> What might be the current known cultrips still in this code? And does
> the setup for the CardDAV part require any special
> actions/considerations or will it work out-of-the-box when I checkout
> the repository and run the normal installation?

You'll need to create a new collection and make it an 'addressbook'
collection. I recommend calling it 'addressbook'.

For the Apple clients it also seems to be necessary to add an SRV
record, which can be non-trivial. I use dnsmasq on my LAN at home, so I
was able to add a line like:

srv-host=_carddav._tcp.home.mcmillan.net.nz.,davical.home.mcmillan.net.nz.,80

into my dnsmasq configuration. Once I'd done that I was able to enter
'home.mcmillan.net.nz' into the 'domain name' field, and it magically
found the mycaldav.home.mcmillan.net.nz host and started doing CalDAV
against port 80.

Cheers,
Andrew.

--
------------------------------------------------------------------------
http://andrew.mcmillan.net.nz/ Porirua, New Zealand
Twitter: _karora Phone: +64(272)DEBIAN
A visit to a fresh place will bring strange work.
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20100623/dc7fdb28/attachment.pgp>
-------------- next part --------------
CardDAV once again... [ In reply to ]
Hi Andrew,

Am 23.06.10 13:41, schrieb Andrew McMillan:

> On Wed, 2010-06-23 at 08:05 +0200, Jens Langner wrote:
>>
>> Wow, this sounds promising. Are these changes already in your public
>> source code repository (http://repo.or.cz/w/davical.git) so that I can
>> test them myself on my own server and probably give some direct feedback
>> to you - even before friday? ;)
>
> It is now, including a change or two to AWL, which you'd also need to
> fetch from http://repo.or.cz/w/awl.git . It's working with Evolution's
> WebDAV Addressbook plugin now, as well.

Ok, I did a complete clean install on my linux server of the current
sources which are in your git.

>> What might be the current known cultrips still in this code? And does
>> the setup for the CardDAV part require any special
>> actions/considerations or will it work out-of-the-box when I checkout
>> the repository and run the normal installation?
>
> You'll need to create a new collection and make it an 'addressbook'
> collection. I recommend calling it 'addressbook'.

Ok, I also manually created an 'addressbook' collection to test the
carddav support in DAViCal.

> For the Apple clients it also seems to be necessary to add an SRV
> record, which can be non-trivial. I use dnsmasq on my LAN at home, so I
> was able to add a line like:
>
> srv-host=_carddav._tcp.home.mcmillan.net.nz.,davical.home.mcmillan.net.nz.,80
>
> into my dnsmasq configuration. Once I'd done that I was able to enter
> 'home.mcmillan.net.nz' into the 'domain name' field, and it magically
> found the mycaldav.home.mcmillan.net.nz host and started doing CalDAV
> against port 80.

Thanks for the hint. I just did that now and added the SRV entries in
the public DNS entries of my name server.

So after having installed a clean new version of DAViCal I was
successfully able to connect the iCal client of OSX (10.6.4) with my new
installation of DAViCal. And to even give you some more feedback, I was
also perfectly able to connect to the server from my iPhone (iOS4).
However, I had to enter a full "https://XXXXXX:pppp" URL to get both
clients finding out the correct path so that they recognize my server as
a valid CardDAV server.

After my first test with creating new addressbook entries both in iCal
and my iPhone, I have to unfortunately report that things are not
working quite fine. For example, I was able to create new addressbook
entries in iCal without any error message and I can also see that in the
new 'addressbook' collection the web interface of DAViCal tells me that
there are new 'Items' (Items count increased by one). However, as soon
as I remove the account from iCal, restart it and reconnect it to my
DAViCal server it doesn't show the newly created addressbook entry.
The same goes for the iPhone. I am able to create new addressbook
entries, but as soon as I remove the account and reconnect to DAViCal,
all the newly created addressbook entries are gone. Even more annoying
is, that I can't see the entries I just created by iCal and vice versa.

So things are not working very smoothly right now aside the connection
as a CardDAV client.

Do you have any additional instructions you can provide me to debug the
situation in helping you to fix the last minor bits so that we will have
a working CardDAV support soonish ;)

Nevertheless, I would really like to thank you for your overwhelming
work in helping us to get an own private CalDAV/CardDAV service apart
from mobile me&co ;)

regards,
jens
--
Jens Langner, Dresden/Germany
http://www.jens-langner.de/
CardDAV once again... [ In reply to ]
On Jun 23, 2010, at 4:41 AM, Andrew McMillan wrote:

> You'll need to create a new collection and make it an 'addressbook'
> collection. I recommend calling it 'addressbook'.
>
Naive question: how to I create a new collection?

> For the Apple clients it also seems to be necessary to add an SRV
> record, which can be non-trivial. I use dnsmasq on my LAN at home, so I
> was able to add a line like:
>
> srv-host=_carddav._tcp.home.mcmillan.net.nz.,davical.home.mcmillan.net.nz.,80
>
> into my dnsmasq configuration. Once I'd done that I was able to enter
> 'home.mcmillan.net.nz' into the 'domain name' field, and it magically
> found the mycaldav.home.mcmillan.net.nz host and started doing CalDAV
> against port 80.


For my name server zone file I added a line like this:

_carddav._tcp.sabath.seattle.wa.us. IN SRV 10 5 80 calendar.sabath.seattle.wa.us.

Does this look right?

Thanks,

Dan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20100623/6aa4bd37/attachment.htm>
-------------- next part --------------
CardDAV once again... [ In reply to ]
On Wed, 2010-06-23 at 16:51 +0200, Jens Langner wrote:
> Hi Andrew,
>
> Am 23.06.10 13:41, schrieb Andrew McMillan:
>
> > On Wed, 2010-06-23 at 08:05 +0200, Jens Langner wrote:
> >>
> >> Wow, this sounds promising. Are these changes already in your public
> >> source code repository (http://repo.or.cz/w/davical.git) so that I can
> >> test them myself on my own server and probably give some direct feedback
> >> to you - even before friday? ;)
> >
> > It is now, including a change or two to AWL, which you'd also need to
> > fetch from http://repo.or.cz/w/awl.git . It's working with Evolution's
> > WebDAV Addressbook plugin now, as well.
>
> Ok, I did a complete clean install on my linux server of the current
> sources which are in your git.
>
> >> What might be the current known cultrips still in this code? And does
> >> the setup for the CardDAV part require any special
> >> actions/considerations or will it work out-of-the-box when I checkout
> >> the repository and run the normal installation?
> >
> > You'll need to create a new collection and make it an 'addressbook'
> > collection. I recommend calling it 'addressbook'.
>
> Ok, I also manually created an 'addressbook' collection to test the
> carddav support in DAViCal.
>
> > For the Apple clients it also seems to be necessary to add an SRV
> > record, which can be non-trivial. I use dnsmasq on my LAN at home, so I
> > was able to add a line like:
> >
> > srv-host=_carddav._tcp.home.mcmillan.net.nz.,davical.home.mcmillan.net.nz.,80
> >
> > into my dnsmasq configuration. Once I'd done that I was able to enter
> > 'home.mcmillan.net.nz' into the 'domain name' field, and it magically
> > found the mycaldav.home.mcmillan.net.nz host and started doing CalDAV
> > against port 80.
>
> Thanks for the hint. I just did that now and added the SRV entries in
> the public DNS entries of my name server.
>
> So after having installed a clean new version of DAViCal I was
> successfully able to connect the iCal client of OSX (10.6.4) with my new
> installation of DAViCal. And to even give you some more feedback, I was
> also perfectly able to connect to the server from my iPhone (iOS4).
> However, I had to enter a full "https://XXXXXX:pppp" URL to get both
> clients finding out the correct path so that they recognize my server as
> a valid CardDAV server.

It's likely that you also need the rewrite rules linked from the 'Setup
for Apple users' page in the wiki. I have these on my development
system but I thought that it *might* have worked without them.


> After my first test with creating new addressbook entries both in iCal
> and my iPhone, I have to unfortunately report that things are not
> working quite fine. For example, I was able to create new addressbook
> entries in iCal without any error message and I can also see that in the
> new 'addressbook' collection the web interface of DAViCal tells me that
> there are new 'Items' (Items count increased by one). However, as soon
> as I remove the account from iCal, restart it and reconnect it to my
> DAViCal server it doesn't show the newly created addressbook entry.
> The same goes for the iPhone. I am able to create new addressbook
> entries, but as soon as I remove the account and reconnect to DAViCal,
> all the newly created addressbook entries are gone. Even more annoying
> is, that I can't see the entries I just created by iCal and vice versa.
>
> So things are not working very smoothly right now aside the connection
> as a CardDAV client.
>
> Do you have any additional instructions you can provide me to debug the
> situation in helping you to fix the last minor bits so that we will have
> a working CardDAV support soonish ;)

If you can switch to http, rather than https, then you can use Wireshark
or something like that to sniff the client/server traffic. Wireshark
then has a 'Follow TCP Stream' option which pulls all the packets into a
'readable' communication stream. It's likely that there are some errors
of some kind or another appearing in the stream and causing it to be
invalid.

Any information would be useful. I just checked here, and I can see
newly added entries, and see them again if I delete the account and
re-add it.


> Nevertheless, I would really like to thank you for your overwhelming
> work in helping us to get an own private CalDAV/CardDAV service apart
> from mobile me&co ;)

Whatever I can do to ensure the whole world doesn't get 'Steved' :-)

Cheers,
Andrew.
--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Good day for overcoming obstacles. Try a steeplechase.
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20100624/23d2c3c6/attachment.pgp>
-------------- next part --------------
CardDAV once again... [ In reply to ]
On Wed, 2010-06-23 at 17:34 -0700, Daniel E. Sabath wrote:
>
> On Jun 23, 2010, at 4:41 AM, Andrew McMillan wrote:
>
> > You'll need to create a new collection and make it an 'addressbook'
> > collection. I recommend calling it 'addressbook'.
> >
> Naive question: how to I create a new collection?
>
> > For the Apple clients it also seems to be necessary to add an SRV
> > record, which can be non-trivial. I use dnsmasq on my LAN at home,
> > so I
> > was able to add a line like:
> >
> > srv-host=_carddav._tcp.home.mcmillan.net.nz.,davical.home.mcmillan.net.nz.,80
> >
> > into my dnsmasq configuration. Once I'd done that I was able to
> > enter
> > 'home.mcmillan.net.nz' into the 'domain name' field, and it
> > magically
> > found the mycaldav.home.mcmillan.net.nz host and started doing
> > CalDAV
> > against port 80.
>
>
> For my name server zone file I added a line like this:
>
>
> _carddav._tcp.sabath.seattle.wa.us. IN SRV 10 5 80
> calendar.sabath.seattle.wa.us.
>
>
> Does this look right?

Looks right to me.

I guess you can do:

dig SRV _carddav._tcp.sabath.seattle.wa.us

to check that it's working.

Cheers,
Andrew.


--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
You love peace.
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20100624/6e29df8c/attachment-0001.pgp>
-------------- next part --------------
CardDAV once again... [ In reply to ]
Hi Andrew,

Am 24.06.10 02:43, schrieb Andrew McMillan:

[...]
>> So after having installed a clean new version of DAViCal I was
>> successfully able to connect the iCal client of OSX (10.6.4) with my new
>> installation of DAViCal. And to even give you some more feedback, I was
>> also perfectly able to connect to the server from my iPhone (iOS4).
>> However, I had to enter a full "https://XXXXXX:pppp" URL to get both
>> clients finding out the correct path so that they recognize my server as
>> a valid CardDAV server.
>
> It's likely that you also need the rewrite rules linked from the 'Setup
> for Apple users' page in the wiki. I have these on my development
> system but I thought that it *might* have worked without them.

Well, haven't tested that yet, but in fact it worked fine when entering
an URL like "https://host.domain:port" right away where it asks for the
server name. After that iCal and the iPhone connected fine to DAViCal.
However, the problem with the vanishing items in the addressbook
collection remains.

[...]
>> Do you have any additional instructions you can provide me to debug the
>> situation in helping you to fix the last minor bits so that we will have
>> a working CardDAV support soonish ;)
>
> If you can switch to http, rather than https, then you can use Wireshark
> or something like that to sniff the client/server traffic. Wireshark
> then has a 'Follow TCP Stream' option which pulls all the packets into a
> 'readable' communication stream. It's likely that there are some errors
> of some kind or another appearing in the stream and causing it to be
> invalid.

Isn't there another way instead of using Wireshark? Because here I can
only test it with my main server system and there I don't have any
wireshark installed. In addition I would rather not switch to plain http
for security reasons. Isn't there some kind of debug output of DAViCal
which might help you in understanding what is going wrong on my side?

> Any information would be useful. I just checked here, and I can see
> newly added entries, and see them again if I delete the account and
> re-add it.

Strange. Here I really tried hard to get that solve. But I am stuck with
always the same behaviour: As soon as I remove the account from iCal and
re-add it, the created entries are not showing up. Interestingly, if I
have a look at the database table 'addressbook_resource' I can see items
in there. Unfortunately they don't seem to get propagated to the clients
somehow.

regards,
jens
--
Jens Langner, Dresden/Germany
http://www.jens-langner.de/
CardDAV once again... [ In reply to ]
On Thu, 2010-06-24 at 13:45 +0200, Jens Langner wrote:
>
> Well, haven't tested that yet, but in fact it worked fine when entering
> an URL like "https://host.domain:port" right away where it asks for the
> server name. After that iCal and the iPhone connected fine to DAViCal.
> However, the problem with the vanishing items in the addressbook
> collection remains.

OK.

I've fixed a few more items (just committing them now). I can't seem to
get the CardDAV working on the iphone though. It doesn't do the SRV
lookup, but it does make the request against the /.well-known/carddav
URL, and finds the addressbook OK, but then just seems to get stuck in a
loop doing:

PROPFIND addressbook (depth 0) for getctag
PROPFIND addressbook (depth 1) for getetag

But it goes no further, and then when it's time to refresh it just does
the same thing over again. Very frustrating. I've examined the
response for both those requests, and I can't see an issue with either
one.

Attempting to add an entry I never see a PUT from the client.


On iCal it goes further (and takes a different route) but ends up in a
somewhat similar loop of:

PROPFIND addressbook (depth 0) for getctag
PROPFIND addressbook (depth 1) for getetag
REPORT calendar-multiget on addressbook for each of the records it saw
in the PROPFIND for getetag

But it never displays those records it has retrieved.

Attempting to add an entry, in this case I *do* see the PUT, and the
entry is added, showing up in subsequent PROPFIND and REPORT requests,
but whether it is displayed seems to bear no resemblance to whether it
is present or not.


> > If you can switch to http, rather than https, then you can use Wireshark
> > or something like that to sniff the client/server traffic. Wireshark
> > then has a 'Follow TCP Stream' option which pulls all the packets into a
> > 'readable' communication stream. It's likely that there are some errors
> > of some kind or another appearing in the stream and causing it to be
> > invalid.
>
> Isn't there another way instead of using Wireshark? Because here I can
> only test it with my main server system and there I don't have any
> wireshark installed. In addition I would rather not switch to plain http
> for security reasons. Isn't there some kind of debug output of DAViCal
> which might help you in understanding what is going wrong on my side?

There is a $c->dbg['request'] = 1; $c->dbg['response'] = 1; pair of
settings which you can use, but these settings only show what DAViCal
thinks it's sending (the request is, at least, reliable) - they don't
include error output screwing stuff up.

I figured if you were debugging this stuff that you were running on a
test setup, not with real passwords or anything. Sure: for security SSL
is a better choice.


> Strange. Here I really tried hard to get that solve. But I am stuck with
> always the same behaviour: As soon as I remove the account from iCal and
> re-add it, the created entries are not showing up. Interestingly, if I
> have a look at the database table 'addressbook_resource' I can see items
> in there. Unfortunately they don't seem to get propagated to the clients
> somehow.

Yeah. It's odd.

Looks like I might have to find a server that's actually running some
other software and try and get a packet capture to see what might be
different.

Cheers,
Andrew.

--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
You will be recognized and honored as a community leader.
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20100627/2fa86cca/attachment.pgp>
-------------- next part --------------
CardDAV once again... [ In reply to ]
Hi Andrew,

Am 27.06.10 10:37, schrieb Andrew McMillan:

> On Thu, 2010-06-24 at 13:45 +0200, Jens Langner wrote:
>>
>> Well, haven't tested that yet, but in fact it worked fine when entering
>> an URL like "https://host.domain:port" right away where it asks for the
>> server name. After that iCal and the iPhone connected fine to DAViCal.
>> However, the problem with the vanishing items in the addressbook
>> collection remains.
>
> OK.
>
> I've fixed a few more items (just committing them now). I can't seem to
> get the CardDAV working on the iphone though. It doesn't do the SRV
> lookup, but it does make the request against the /.well-known/carddav
> URL, and finds the addressbook OK, but then just seems to get stuck in a
> loop doing:

Have you already committed your changes? Because here
(http://repo.or.cz/w/davical.git) I can only see your last changes done
on Jun 23th which is 4 days ago. However, I have been at least able to
add the carddav account by entering the full URL like I told you above.

> PROPFIND addressbook (depth 0) for getctag
> PROPFIND addressbook (depth 1) for getetag
>
> But it goes no further, and then when it's time to refresh it just does
> the same thing over again. Very frustrating. I've examined the
> response for both those requests, and I can't see an issue with either
> one.
>
> Attempting to add an entry I never see a PUT from the client.

Yes, I also have noticed that as soon as I enter an entry via the iPhone
I never see it appearing in the database. So something might be still
missing in DAViCal...

> On iCal it goes further (and takes a different route) but ends up in a
> somewhat similar loop of:
>
> PROPFIND addressbook (depth 0) for getctag
> PROPFIND addressbook (depth 1) for getetag
> REPORT calendar-multiget on addressbook for each of the records it saw
> in the PROPFIND for getetag
>
> But it never displays those records it has retrieved.
>
> Attempting to add an entry, in this case I *do* see the PUT, and the
> entry is added, showing up in subsequent PROPFIND and REPORT requests,
> but whether it is displayed seems to bear no resemblance to whether it
> is present or not.

That's exactly what I also found and where I stopped doing more work
because I do not know anything on the CardDAV protocol nor do I have
experience in debugging DAViCal.


>> Isn't there another way instead of using Wireshark? Because here I can
>> only test it with my main server system and there I don't have any
>> wireshark installed. In addition I would rather not switch to plain http
>> for security reasons. Isn't there some kind of debug output of DAViCal
>> which might help you in understanding what is going wrong on my side?
>
> There is a $c->dbg['request'] = 1; $c->dbg['response'] = 1; pair of
> settings which you can use, but these settings only show what DAViCal
> thinks it's sending (the request is, at least, reliable) - they don't
> include error output screwing stuff up.

Thanks, I will try to set that and see what it outputs so that we can
perhaps debug the situation a bit better.

>> Strange. Here I really tried hard to get that solve. But I am stuck with
>> always the same behaviour: As soon as I remove the account from iCal and
>> re-add it, the created entries are not showing up. Interestingly, if I
>> have a look at the database table 'addressbook_resource' I can see items
>> in there. Unfortunately they don't seem to get propagated to the clients
>> somehow.
>
> Yeah. It's odd.
>
> Looks like I might have to find a server that's actually running some
> other software and try and get a packet capture to see what might be
> different.

Have you ever tried to do a local install of the official caldav/carddav
server from Apple? It is available here: http://trac.calendarserver.org/
and just consists of python AFAICS. I have already done a local install
here but stopped with configuring it as soon as I figured you are
working on CardDAV support. But perhaps it would be good to have a look
what they are doing and try to replicate that in DAViCal as well.

regards,
jens
--
Jens Langner, Dresden/Germany
http://www.jens-langner.de/
CardDAV once again... [ In reply to ]
On Mon, 2010-06-28 at 11:58 +0200, Jens Langner wrote:
> Hi Andrew,
>
> Am 27.06.10 10:37, schrieb Andrew McMillan:
>
> > On Thu, 2010-06-24 at 13:45 +0200, Jens Langner wrote:
> >>
> >> Well, haven't tested that yet, but in fact it worked fine when entering
> >> an URL like "https://host.domain:port" right away where it asks for the
> >> server name. After that iCal and the iPhone connected fine to DAViCal.
> >> However, the problem with the vanishing items in the addressbook
> >> collection remains.
> >
> > OK.
> >
> > I've fixed a few more items (just committing them now). I can't seem to
> > get the CardDAV working on the iphone though. It doesn't do the SRV
> > lookup, but it does make the request against the /.well-known/carddav
> > URL, and finds the addressbook OK, but then just seems to get stuck in a
> > loop doing:
>
> Have you already committed your changes? Because here
> (http://repo.or.cz/w/davical.git) I can only see your last changes done
> on Jun 23th which is 4 days ago. However, I have been at least able to
> add the carddav account by entering the full URL like I told you above.

I have now.


> Yes, I also have noticed that as soon as I enter an entry via the iPhone
> I never see it appearing in the database. So something might be still
> missing in DAViCal...

I now have a trace from a server which the iPhone did (sort of)
interoperate with (though not a trace of the iPhone accessing it), so
hopefully I'll be able to go through that over the next few days and
work out exactly what the differences are in our responses.


> Have you ever tried to do a local install of the official caldav/carddav
> server from Apple? It is available here: http://trac.calendarserver.org/
> and just consists of python AFAICS. I have already done a local install
> here but stopped with configuring it as soon as I figured you are
> working on CardDAV support. But perhaps it would be good to have a look
> what they are doing and try to replicate that in DAViCal as well.

I did, some years ago. It has some slightly arcane requirements (the
file system must support extended attibutes, amongst other things) but
I've also seen people on the mailing list lamenting the difficulty of
getting the CardDAV working on Linux...

I will do so again, as a last resort, but I expect some of these interop
issues will also be fixed by Apple in their next release or two. A
similar thing happened with the first releases of iCal and iPhone with
CalDAV support, which were fairly rapidly fixed once people wanted to
use them with other servers.

Cheers,
Andrew.

--
------------------------------------------------------------------------
http://andrew.mcmillan.net.nz/ Porirua, New Zealand
Twitter: _karora Phone: +64(272)DEBIAN
Your nature demands love and your happiness depends on it.
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20100629/5e6e4730/attachment.pgp>
-------------- next part --------------
CardDAV once again... [ In reply to ]
Hi Andrew,

Am 29.06.10 14:01, schrieb Andrew McMillan:

>> Have you already committed your changes? Because here
>> (http://repo.or.cz/w/davical.git) I can only see your last changes done
>> on Jun 23th which is 4 days ago. However, I have been at least able to
>> add the carddav account by entering the full URL like I told you above.
>
> I have now.

Thanks. I checked out the new sources and retried all my previous tests.
Unfortunately it's still the same. Any addressbook entry I add with
iAddressbook will be put into the database. However, as soon as I remove
the account and readd it the entries are gone and not propagated to the
client again. Even worse now, I cannot even use "https://HOST:PORT" in
the "Server address" field anymore and have to add the full path to the
addressbook location in the URL. I also checked my SRV entries in the
DNS and if I just enter "HOST" now in the server address field my
iAddressbook client will complain about that it can't find the
"addressbook" collection for that user. However, it is definitely there.

Regarding a connection from an iOS4 device to the CardDAV part of
DAViCal, I could perfectly replicate your problems here. In fact, while
I am also able to add new entries to the addresbook of my iPhone4, these
entries don't seem to be pushed to DAViCal's database. So while you
probably get the iAddressbook support running quite quickly, support for
the iOS4 addressbook might be more challanging as it seems to behave
slightly different.

>> Yes, I also have noticed that as soon as I enter an entry via the iPhone
>> I never see it appearing in the database. So something might be still
>> missing in DAViCal...
>
> I now have a trace from a server which the iPhone did (sort of)
> interoperate with (though not a trace of the iPhone accessing it), so
> hopefully I'll be able to go through that over the next few days and
> work out exactly what the differences are in our responses.

Oh, that's great. Hope you can find the last issues so that the CardDAV
support starts working in DAViCal. Wouldn't this then be a reason for
another rename of DAViCal" to something more general because now DAViCal
can also talk CardDAV? ;)

>> Have you ever tried to do a local install of the official caldav/carddav
>> server from Apple? It is available here: http://trac.calendarserver.org/
>> and just consists of python AFAICS. I have already done a local install
>> here but stopped with configuring it as soon as I figured you are
>> working on CardDAV support. But perhaps it would be good to have a look
>> what they are doing and try to replicate that in DAViCal as well.
>
> I did, some years ago. It has some slightly arcane requirements (the
> file system must support extended attibutes, amongst other things) but
> I've also seen people on the mailing list lamenting the difficulty of
> getting the CardDAV working on Linux...
>
> I will do so again, as a last resort, but I expect some of these interop
> issues will also be fixed by Apple in their next release or two. A
> similar thing happened with the first releases of iCal and iPhone with
> CalDAV support, which were fairly rapidly fixed once people wanted to
> use them with other servers.

Well, I still hope it is possible to patch DAViCal in a way that it will
work with the current versions of iAddressbook and iOS4. Because updates
for them might not show up that quickly really I am afraid. Or at least
not as quickly as I would need CardDAV support ;)

regards,
jens
--
Jens Langner, Dresden/Germany
http://www.jens-langner.de/