Cal/CardDAV URL implementation error...
-
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.
-
@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:
- ownCloud
- Radicale
- iCloud
-
The problems with this project lie with the following statements: It's less about coding skills and more about BS feminine personalities that worry more about "HOW" you say something than to actually say something. It's more about taking the time to ANALYZE AND UNDERSTAND the DESIGN behind the RFCs...than BSing your way thru them.
[[[ I am fully aware that some servers can be browsed like filesystems. But only some. ]]]
You are arguing against the author of the standard... Have you ever heard of the term "denial" from the field of "psychiatry"?
RFC6764 by Cyrus Daboo -- QUOTE "Locating Services for Calendaring Extensions to
WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV) "If a server can't be surfed by a WebDAV browser (e.g. Konqueror), it's not a Cal/CardDAV server. You defeat the standard. IMHO, If you can't use a WebDAV client (e.g. wget, curl) to recursively load/unload an entire CalDAV server... it ain't a CalDAV server. Dump it!!!
The "big picture" purpose of Cal/CardDAV is to be interoperable with LARGE SYSTEMS such as ERP systems... using WebDAV, too... for mass-scale operations -- not just a little Android telephone to keep track of your favorite NFL Team's schedule for the next big season. "Big picture" includes inter-domain operations -- even between disjoint systems... for example: between Ford Motor Company and its suppliers or subcontractors to schedule production runs of parts for BMW and its suppliers/subcontractors. (NOTE: It could happen.)
I salute and respect Cyrus for his work and efforts to CREATE AN INTEROPERABLE STANDARD -- I don't argue with him... but I will be happy to help analyze a proposal for usability and simplicity.
[[[ And therefore it is inefficient to traverse whatever structure a DAV server has. ]]]
Maybe for a little Android phone... but, you can count bytes, right? Put practical limits within the code to keep track of your memory usage vs availability, right? Use multiple threads, maybe?
It's too big for a supercomputer, right? 64 threads per node? With a multiplexed 500Gbit/sec single mode fiber connection between them?
[[[ 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. ]]]
-
Like I said, don't shoot the messenger. What's the difference between the messenger and the message?
-
If I do, will you argue with everything I do that conforms to the plain-language English RFCs... AND the examples set forth at http://calconnect.org and http://calendarserver.org/ by Cyrus and his associates?
-
-
Two counter-questions instead of one answer: I'll count this as a "no". While it's always worth re-thinking and improving implementations, I don't see much value in this discussion, which is the reason for closing it now.
For improving the auto-detection of resources, please follow up at #439, #465, #533 and other related issues. (And when I say "follow up", I don't mean "spam it".)
And @ddblack:
It's less about coding skills and more about BS feminine personalities that worry more about "HOW" you say something than to actually say something.
I won't tolerate sexist and misogynistic speech here. Don't reply to this warning, I won't discuss it.
Have you ever heard of the term "denial" from the field of "psychiatry"?
The behavior of using the concept of "mental illness" to suppress other people's arguments will not be tolerated, too. Be respectful or you will be blocked the next time.