Cal/CardDAV URL implementation error...

DAVx⁵
Log in to reply
  • A

    I’m trying to reproduce this but can’t find any calendar sharing options in ownCloud 8 ?

    Also, a reminder… Cal/CardDAV is supposed to be recursive.

    I don’t know what you mean by this.

    0
  • A

    Recursion in computer science[1] is a method where the solution to a problem
    depends on solutions to smaller instances of the same problem (as opposed to
    iteration[2]).^{[1]}[3] The approach can be applied to many types of problems, and
    recursion[4] is one of the central ideas of computer science.^{[2]}[5]
    “The power of recursion evidently lies in the possibility of defining an infinite set
    of objects by a finite statement. In the same manner, an infinite number of
    computations can be described by a finite recursive program, even if this program
    contains no explicit repetitions.”^{[3]}[6]
    Most computer programming languages support recursion by allowing a
    function[7] to call itself within the program text. Some functional programming
    languages[8] do not define any looping constructs but rely solely on recursion to
    repeatedly call code. Computability theory[9] has
    proven^{[/attribution needed/[10]]} that these recursive-only languages are Turing
    complete[11]; they are as computationally powerful as Turing complete imperative
    languages, meaning they can solve the same kinds of problems as imperative
    languages even without iterative control structures such as “while” and “for”.

    On Wednesday, June 03, 2015 08:12:02 AM Markus Unterwaditzer wrote:

    I’m trying to reproduce this but can’t find any calendar sharing options in
    ownCloud 8 ?

    Also, a reminder… Cal/CardDAV is supposed to be recursive.

    I don’t know what you mean by this.

    Reply to this email directly or view it on GitHub:
    https://github.com/bitfireAT/davdroid/issues/528#issuecomment-108478083

    [1] http://en.wikipedia.org/wiki/Computer_science
    [2] http://en.wikipedia.org/wiki/Iteration#Computing
    [3] http://en.wikipedia.org/wiki/Recursion_(computer_science)#cite_note-1
    [4] http://en.wikipedia.org/wiki/Recursion
    [5] http://en.wikipedia.org/wiki/Recursion_(computer_science)#cite_note-2
    [6] http://en.wikipedia.org/wiki/Recursion_(computer_science)#cite_note-3
    [7] http://en.wikipedia.org/wiki/Function_(computer_science)
    [8] http://en.wikipedia.org/wiki/Functional_languages
    [9] http://en.wikipedia.org/wiki/Computability_theory_(computer_science)
    [10] http://en.wikipedia.org/wiki/Wikipedia:Attribution_needed
    [11] http://en.wikipedia.org/wiki/Turing_completeness

    0
  • A

    PART TWO… in part… from PROPOSED RFC which explicitly mentions
    “recursively”… Apple Calendar Server and it’s corresponding test battery supports
    it, too. IMHO, Owncloud is not a good choice “standard” for development of
    DAVDroid.

    Calendaring Extensions to WebDAV (CalDAV)

    Note: a later version of this document has been published as RFC4791[1].

    8.[2] Calendaring Reports[3]
    This section defines the reports which a CalDAV server MUST support on calendar
    collections and calendar resources.
    CalDAV servers MUST advertise support for those reports with the DAV:supported-
    report-set property defined in DeltaV[4] /[5]/.
    Some of these reports allow calendar data (from possibly multiple resources) to be
    returned. Clients SHOULD request the DAV:getetag property whenever executing
    reports that return calendar data, to ensure that any local cache used for
    synchronization is kept up to date with the latest changes on the server
    8.1[5] REPORT Method[6]
    The REPORT method (defined in Section 3.6 of RFC3253[4] /[5]/) provides an
    extensible mechanism for obtaining information about a resource. Unlike the
    PROPFIND method, which returns the value of one or more named properties, the
    REPORT method can involve more complex processing. REPORT is valuable in cases
    where the server has access to all of the information needed to perform the
    complex request (such as a query), and where it would require multiple requests
    for the client to retrieve the information needed to perform the same request.
    A server that supports calendar-access MUST support the DAV:expand-property
    report (defined in Section 3.8 of RFC3253 /[5]/).
    8.2[7] 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. These collections may
    contain more than only calendar related resources. It’s up to the server, if it
    supports this REPORT on a normal WebDAV collection, to find calendar resources
    and decide what to do with non-calendar resources and whether those may also
    appear in the collection or its children.
    If these reports are supported on ordinary collections the server advertises the
    capability with the DAV:supported-report-set property as already described.
    8.3[8] CALDAV:calendar-query Report[9]
    The CALDAV:calendar-query REPORT performs a search for all calendar resources
    (e.g., iCalendar objects) that match a specified search filter. The response of this
    report will contain all the WebDAV properties and calendar resource data specified
    in the request. In the case of the CALDAV:calendar-data XML element, one can
    explicitly specify the calendar components and properties that should be returned
    in the calendar resource data that matches the search filter.
    The format of this report is modeled on the PROPFIND method. The request and
    response bodies of the CALDAV:calendar-query report use XML elements that are
    also used by PROPFIND. In particular the request can include XML elements to
    request WebDAV properties to be returned. When that occurs the response should
    follow the same behavior as PROPFIND with respect to the DAV:multistatus
    response elements used to return specific property results. For instance, a request
    to retrieve the value of a property which does not exist is an error and MUST be
    noted with a response XML element which contains a 404 (Not Found) status value.
    Support for the calendar-query REPORT is REQUIRED.
    Marshalling:
    * The request body MUST be a CALDAV:calendar-query XML element as defined
    in Section 10.1[10].
    * The response body for a successful request MUST be a DAV:multistatus XML
    element (i.e., the response uses the same format as the response for PROPFIND).
    In the case where there are no response elements, the returned multistatus XML
    element is empty.
    * The response body for a successful calendar-query REPORT request MUST
    contain a DAV:response element for each iCalendar object that matched the search
    filter. The declaration of the DAV:response element from Section 12.9.1 of
    RFC2518[11] /[3]/ has been modified as follow to allow the CALDAV:calendar-data
    element within the DAV:response element, see Section 10.5[12]
    [rfc.comment.4[13]: We need to define the role of the Depth request header when
    applied to a collection resource. We need to specify preconditions and
    postconditions. (e.g., DAV:number-of-matches-within-limits). --desruisseaux]

    On Wednesday, June 03, 2015 08:12:02 AM Markus Unterwaditzer wrote:

    I’m trying to reproduce this but can’t find any calendar sharing options in
    ownCloud 8 ?

    Also, a reminder… Cal/CardDAV is supposed to be recursive.

    I don’t know what you mean by this.

    Reply to this email directly or view it on GitHub:
    https://github.com/bitfireAT/davdroid/issues/528#issuecomment-108478083

    [1] http://greenbytes.de/tech/webdav/rfc4791.html
    [2] http://greenbytes.de/tech/webdav/draft-dusseault-caldav-05.html#rfc.section.8
    [3] http://greenbytes.de/tech/webdav/draft-dusseault-caldav-05.html#reports
    [4] http://greenbytes.de/tech/webdav/draft-dusseault-caldav-05.html#RFC3253
    [5] http://greenbytes.de/tech/webdav/draft-dusseault-caldav-05.html#rfc.section.8.1
    [6] http://greenbytes.de/tech/webdav/draft-dusseault-caldav-05.html#METHOD_REPORT
    [7] http://greenbytes.de/tech/webdav/draft-dusseault-caldav-05.html#rfc.section.8.2
    [8] http://greenbytes.de/tech/webdav/draft-dusseault-caldav-05.html#rfc.section.8.3
    [9] http://greenbytes.de/tech/webdav/draft-dusseault-caldav-05.html#calendar-query
    [10] http://greenbytes.de/tech/webdav/draft-dusseault-caldav-05.html#calendar_query_element
    [11] http://greenbytes.de/tech/webdav/draft-dusseault-caldav-05.html#RFC2518
    [12] http://greenbytes.de/tech/webdav/draft-dusseault-caldav-05.html#response_element
    [13] http://greenbytes.de/tech/webdav/draft-dusseault-caldav-05.html#rfc.comment.4

    0
  • A

    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.

    0
  • A

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

    0
  • A

    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.

    0
  • A

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

    0
  • A

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

    0
  • A

    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

    0
  • A

    [[[ 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?

    0
  • A

    http://askubuntu.com/questions/104046/how-do-i-recursively-copy-download-a-whole-webdav-directory

    0
  • A

    http://www.webdav.org/perldav/dave.html

    0
  • A

    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.

    0
  • A

    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?

    0
  • A

    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

    0
  • A

    It’s crazy that between all this that @ddblack has still not managed to explain the actual issue that he’s having 😕

    0
  • A

    Evert… Please read the first post and go away, please!

    0
  • A

    @ddblack As said, you’re hiding it between a lot of unrelated things. No wonder people miss it.

    0
  • A

    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!

    0
  • A

    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.

    0

Similar topics

  • J


    DAVx⁵ •

    8
  • J


    DAVx⁵ •

    3
  • A


    DAVx⁵ •

    6