Cal/CardDAV URL implementation error...
CalDAV/CardDAV is a RECURSIVE STRUCTURE… just like a file directory tree.
ALL TREES work the same way… there’s a top and branches… and RECURSIVE
ALGORITHMS are the most efficient method known to computer programmers to
solve these trees.
No it is not a tree, and to my knowledge this requirement is not specified in
the RFC. In fact, Apple’s iCloud servers themselves don’t represent collection
items as subpaths of collections.
If you had actually looked at how *DAV-servers worked, or maybe even read the
RFC correctly instead of just looking one or two implementations, you would
know that DAV-services can be described as directed graphs at best.
Even if the RFC required that all users and collections have to be represented
as a tree, there will be enough servers that disobey the RFC.
Your original report makes sense (at least to me), but you are hiding it
between your masturbatory and utterly irrelevant computer science references.
On Wed, Jun 03, 2015 at 11:39:44PM -0700, ddblack wrote:
[[[ Also it’d be real nice of you @ddblack to tell us the server you’re using. ]]]
DAViCal… and Apple …
[[[ Thanks @evert, I wasn’t aware of @ddblack’s previous bug reports. I agree with what you’ve said regarding @ddblack’s communication style. ]]]
Don’t shoot the messenger.
[[[ DavDroid did its collection discovery dance instead and found other collections, but not this one. I think this is intended behavior in DavDroid since all collections of interest are usually found through this method, but I also think it’d be a good feature to accept direct links to collections. ]]]
Note your use of the word “usually”… This is incorrect.
CalDAV/CardDAV is a RECURSIVE STRUCTURE… just like a file directory tree. ALL TREES work the same way… there’s a top and branches… and RECURSIVE ALGORITHMS are the most efficient method known to computer programmers to solve these trees.
Computer Science 101.
Reply to this email directly or view it on GitHub:
[[[ No it is not a tree, ]]]
Yes it is. Would you like me to draw one for you?
[[[ DAV-services can be described as directed graphs ]]]
[[[ Even if the RFC required that all users and collections have to be represented
as a tree, there will be enough servers that disobey the RFC. ]]]
[[[ between your masturbatory and utterly irrelevant computer science references ]]]
Time for youporn?
In practice, CalDAV is not WebDAV, despite what the RFC makes you believe. I already told you that CalDAV-services can’t be traversed “just like a tree”, with a specific example.
And if you’re looking for a server that breaks just about every assumption you can reasonably have about CalDAV, take a look at Radicale.
Also you’re completely missing the possibility that DAV servers are mounted on subpaths on webservers, which is the case with e.g. ownCloud. In that case you can’t “just traverse” from the root, even if the server implemented all of WebDAV.
BTW I think you have the same issue as https://github.com/bitfireAT/davdroid/issues/439, basically DavDroid seems to ignore the given URL’s path and always try well-known URLs?
I can traverse mine… Try konqueror
Sent with AquaMail for Android
On June 4, 2015 3:23:04 AM Markus Unterwaditzer firstname.lastname@example.org
In practice, CalDAV is not WebDAV, despite what the RFC makes you believe.
I already told you that CalDAV-services can’t be traversed “just like a
tree”, with a specific example.
Reply to this email directly or view it on GitHub:
It’s crazy that between all this that @ddblack has still not managed to explain the actual issue that he’s having
Evert… Please read the first post and go away, please!
@ddblack As said, you’re hiding it between a lot of unrelated things. No wonder people miss it.
I’m not the one hiding.
Traverse the trees yourself… Use Konqueror… webdavs://blahblahblah.
well known URIs and DNS SRV/TXT ARE DEFAULTS (in the absense of a user actually specifying a “root” for the tree, or any part thereof, that he/she wants.)
I’m not hiding anything. The reality is that the reader(s) of this bug report are clueless. Sorta like trying to explain something in English to someone who speaks Polish.
DAVDroid interpretation and implementation are both … wrong. Of course, YOUR confusion is the reason you think I am the one hiding. NOT!
You are hiding your legitimate points between loads of bullshit and additionally ignoring my own points. I don’t even know which point you’re making, and frankly I don’t care anymore. You’re a blithering idiot.
Unreal. Reread the first post… it doesn’t get any plainer than that.
Did you read my first comment? What kind of resource is
What difference does it make? The user-specific URI is substituted before you can retrieve its properties? The contents of the URI will be more folders… (of the tree)… or ics files… or vcs files… or both.
Im serious too… break out your linux box… install Konqueror… and “surf” the Cal/CardDAV Tree(s). They can legally be of any depth and width… because it’s recursive. Most Cal/CardDAV CLIENT implementations are wrong… using iterative, non-recursive algos.
Unless you are Apple or Cyrus Daboo.
FROM #497… QUOTE RFC2822: [[[ I’m with you that the implementation is only partly (BTW, I rarely know implementations that cover the spec to 100%, although it’s the goal to achieve in most cases).]]]
Seems that #497, #439, and #528 – this one – (and probably others) bugs all result from the same LAZY programming “hack” of RFC6764.
I was correct on all counts. Don’t shoot the messenger.
Hopefully by now, you’ve also dabbled with Konqueror and learned that Cal/CardDAV is indeed a ‘surfable’ recursive tree structure [not a “directed graph”] and can be of unlimited dimensions; and, that the Cal/CardDAV client configuration URI can make a relative root out of any branch of the local system’s tree.
AND, that the DNS SRV / TXT records should resolve to the system root of the Cal/CardDAV tree for the DNS ZONE… (determined by the sysadmin)
AND, that well-known will normally be configured to make a relative root of the default login user’s tree – in the absence of a specific, usable URI – but, in fact, it can point to any part of the local system tree… (determined by the sysadmin)
AND, when considering the context of system- (aka “Cal/CardDAV resources”) or user-shared nodes via ACLs, all siblings shall be queried/listed and traversed.
Done correctly as described, an authenticated user would be presented with a complete view of all Cal/CardDAV resources (‘nodes’) authorized to the authenticated user.
@ddblack, could you please volunteer to provide some code for DAVdroid in this regard? I’d really like to learn from your superior skills. After all, it’s open source and you seem to use it, too.
and can be of unlimited dimensions
And therefore it is inefficient to traverse whatever structure a DAV server has.
You don’t prove anything by claiming that some KDE browser can browse a specific server. I am fully aware that some servers can be browsed like filesystems. But only some.
Also I’d like to see your implementation of a client that works on at least the following servers: