Cal/CardDAV URL implementation error...


  • Thanks @evert, I wasn’t aware of @ddblack’s previous bug reports. I agree with what you’ve said regarding @ddblack’s communication style.

    I think @ddblack entered a direct URL to some collection and expected this particular collection to sync. 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.

    @ddblack does this accurately describe your situation?

    Ok, so that’s me trying to help. Now regarding @ddblack’s style:

    It’s obvious to anyone who knows how to write a bash script to traverse a file directory tree…
    because DAVDroid’s doesn’t interpret and implement recursive algorithms and design.

    That remark is even less relevant or qualified than your previous ones combined. It’s completely unclear how this issue has anything to do at all with recursion.


  • Also it’d be real nice of you @ddblack to tell us the server you’re using.


  • [[[ 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 traverse these trees.

    Computer Science 101.

    http://www.cs.cornell.edu/courses/cs3110/2012sp/lectures/lec20-master/lec20.html

    THE BEST EXAMPLEs AND EXPLANATION OF THEM ALL…

    http://webdocs.cs.ualberta.ca/~holte/T26/rec-prog-tech.html
    http://perlmaven.com/recursive-subroutines

    AND… IF YOU PREFER JAVA…
    http://docs.oracle.com/javase/tutorial/essential/io/walk.html


  • 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:
    https://github.com/bitfireAT/davdroid/issues/528#issuecomment-108750984


  • [[[ 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 ]]]

    WTF?

    [[[ 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. ]]]

    Unbelievable.

    [[[ 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
    http://www.aqua-mail.com

    On June 4, 2015 3:23:04 AM Markus Unterwaditzer notifications@github.com
    wrote:

    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:
    https://github.com/bitfireAT/davdroid/issues/528#issuecomment-108781155


  • 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.

    EASY!

    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 https://mail.example.com/caldav.php/PublicResource ?


  • 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.

    http://en.wikipedia.org/wiki/Tree_structure

Similar topics