Cal/CardDAV URL implementation error...


  • Disclaimer, I am not a member of this project, so anything I say is not representative for this project

    @untitaker obviously knew what recursion meant, just not within the context of what you are asking. Instead of copy-pasting parts of the spec, how about trying to do a better job telling what’s wrong.

    The problem with what you pasted is that it’s indeed a DRAFT and the parts mentioning recursion are not in the final specification.

    However, even if this were the standard, this has little to do with the issue brought forward. The only paragraph mentioning recursion is this:

    Reports on collections containing calendars* A WebDAV collection which contains one or more calendar collections is not a new type of resource, but it may support these new REPORT. If so, then the REPORT is expected to have the semantics of including information from all the calendar data contained in the collection, and its children, recursively.

    Which clearly states this as a MAY, not a MUST or even a SHOULD.

    But even if it said MUST, this paragraph only addresses certain REPORT requests on calendar collection. The specification says nothing about how or why the client should take advantage of it.

    Despite your usual incredibly condescending and poorly written bug report, I have two potential guesses as to what your actual issue might be. Perhaps this helps you communicate your root problem:

    • Some clients and servers support regular collections in the ‘calendar home’, which in turn may contain calendars themselves. There is some language in RFC 4791 that does seem to support this concept, but support for this is in general poor. I don’t think it’s unlikely that this will be dropped in future versions of this spec. It’s possible that you are trying to do this on the server, and it’s possible that DavDroid does not support this.

    • You put in a random url and expect the client to work. What’s unclear what type of resource the url is. I don’t think clients are expected to support just any resource containing calendar collections. Many clients do support providing arbitrary urls to principals. The big question is then, what kind of resource is https://mail.example.com/caldav.php/PublicResource in your example?

    Am I close?

    In case anyone reads this and wonders why I would respond as strongly as I did, go read #497 to get another glimpse of @ddblack 's communication style.


  • [[[ The problem with what you pasted is that it’s indeed a DRAFT and the parts mentioning recursion are not in the final specification. ]]]

    It’s obvious to anyone who knows how to write a bash script to traverse a file directory tree…

    Unreal.

    The purpose of this bug report and other related ones due to the fact that DAVDroid doesn’t interpret and implement recursive algorithms and design.


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

Similar topics