I hope WebDAV dies
unterwaditzer.net
unterwaditzer.net
The vCard "group construct" (see rfc6350) is one of the dumbest things ever added to a spec. It seems a trivial thing to add, but completely screws up your internal storage and manipulation formats. It's horrible, on top of all the other horribleness that is vCard.
Of course, I'm biased, given we're trying to push alternatives to IMAP, CardDAV and CalDAV - http://jmap.io/ - but please do check it out. Having actually worked on IMAP servers and clients, CalDAV servers and clients and CardDAV servers and clients, we've learned a lot about creating a saner alternative.
You're giving me so many ideas right now for a follow-up post.
>but vCard and iCal as well
The group construct is bad, the syntax is bad, but other than that, I never had to implement or parse it properly. Vdirsyncer is mostly passing strings through.
I suspect that this part is much harder to replace than CardDAV and CalDAV, since it's not just a file structure with a ton of bullcrap on top of it. For that reason I currently have those file formats in the remoteStorage folder structure i'm syncing to, but it's still a step forward. I might switch to jCard and jCal, but I don't think it'd be worth the breakage.
Personally, I'd prefer a dumb storage with a generic API over yet another custom protocol/API just for these data formats alone. Worked great on people's local drives before the Web, and I think it should work similar on the Web.
If the server has no ability to tell you what changed, then you're left with having to download and check everything. On a large data set, that's pretty much impossible to do quickly and without a lot of network traffic.
Of course, no server is actually that dumb - even a file listing with file sizes can get you part of the way there. But if you've got 10000 files in a file store, that list can still get pretty heavy. If you're willing to make the server smarter, eventually you can get to the point where the server can give you only what changed since the last time you checked. JMAP isn't unique in this; IMAP has MODSEQs, *DAV has collection synchronisation, etc.
JMAP specifically doesn't really care much about the actual format of the data it works with. The only thing it really needs is an immutable ID, so you could use the same model to store all sorts of things (and at FastMail we do, with things like client settings).
Exactly. remoteStorage has ETAGs in folder listings for that. The point is that you can implement a folder structure that enables you to update say just the last week of events plus upcoming ones, which is usually nowhere near 10000. Except with CalDAV you can't (according to the article, I haven't actually looked into it myself).
* I didn't know JMAP was also about calendar and contacts.
* Those parts seem nice.
* However, I'm the kinda guy who self-hosts his data servers. JMAP seems like a powerful protocol. I'm not sure those two things mix well, since JMAP server implementations probably will require a good database, not just a dumb FS like in remoteStorage.
* However, I would like to collaborate wherever possible.
To do JMAP well you need to be able to calculate change sets, which does mean a database, though a fairly light one. I think you could do a server without delta updates by always returning a cannotCalculateChanges error in response to getUpdates calls, but it would be very inefficient on both the client and the wire.
> However, I would like to collaborate wherever possible.
Sure! Best place to start is probably the jmap-discuss list:
https://groups.google.com/forum/#!forum/jmap-discussThere's a demo/beta DAV<->JMAP proxy out there by fastmail. You might want to look into that (and keep the current DAV backend in the meantime).
The service is not running with all of the security measures employed on a production site such as FastMail, so DO NOT USE THIS PROXY FOR ACCOUNTS WITH SENSITIVE DATA.
Of course it stands to reason that one shouldn't grant access to third parties to one's gmail, but you may save some heartache from people who are enthusiastic-past-the-point-of-reason if you move that bit up.
I would have just sent you a PR but proxy.jmap.io isn't hosted on github pages.
It was a total mess and headache the entire time - mostly because the standard implementations that you would attempt to use in a FOSS environment are complete abandonware.
I am speaking of mod_dav on apache. It's abandonware. The original authors cannot be contacted, it lies stagnant ... it's broken.
One of the original reasons that we supported webDAV was that the mac finder, with it's "Connect to Server" choice in the "Go" menu supported webDAV - but their webDAV was really, really quirky and non-standard and did not function well with anything. We had to reverse engineer Apples weirdness and even then it rarely worked well. MS DAV in office, etc. - also weird. And again, very difficult to even work around the weirdness because mod_dav was abandoned.
Giving up on DAV was a win-win - not only did we stop wasting time on these bizarro home-grown dialects of DAV, but we also removed a ton of attack surface by removing apache entirely from rsync.net storage arrays. Nowadays it's just OpenSSH and I think it will stay that way.
wistful: If only (if only!) Apple would support SFTP in the "connect to server" function of the Finder.
It seems so simple and obvious ... would have saved humanity millions of man hours with people mucking around with sshFS/FUSE on their macs, which barely worked back then ...
Mostly due to a lack of enthusiasm from Filesys::Virtual to add the hooks I needed.
It's still powering the FastMail DAV filestorage service, and running fine.
Instead of (or in addition to) considering remoteStorage, one could also go back to "normal" WebDAV, if such a thing exists, and completely forget about the CalDAV/CardDAV servers.
I'd say WebDAV is more mature, it has litmus[1] for testing implementations. remoteStorage has as far as I know only one production instance running at 5apps [2]. The benefits of using the RS protocol are mostly due to the CORS headers (which could be implemented easily for WebDAV) and the use of OAuth/Bearer, for which a PR exists for SabreDAV [3]. One thing missing from WebDAV is the (implicit) mapping of OAuth scopes to ACLs, which should not be too difficult to implement... The discovery, by depending on Webfinger, is also not one of my favorites. I'd prefer something like OAuth authorization server discovery [4].
I mean, I am not opposed to using remoteStorage and love JSON as much as the next guy, but it just doesn't bring (in my opinion) many benefits and loses interop with existing WebDAV clients for no good reason...
[0] https://datatracker.ietf.org/doc/draft-dejong-remotestorage/
[1] http://www.webdav.org/neon/litmus/
> remoteStorage has as far as I know only one production instance running at 5apps
That's not true. 5apps is running the only public service for end users at the moment, but there are certainly more production instances running.
> The benefits of using the RS protocol are mostly due to the CORS headers (which could be implemented easily for WebDAV) and the use of OAuth/Bearer, for which a PR exists for SabreDAV [3].
As both of these would be optional additions to WebDAV servers, all of WebDAV's benefits parish with most servers not supporting these new extensions. That's the very critique in the article as far as I understand. WebDAV alone is not good enough, and optional additions lead to a world of incompatibility and pain.
> One thing missing from WebDAV is the (implicit) mapping of OAuth scopes to ACLs, which should not be too difficult to implement
And another addition.
> I'd prefer something like OAuth authorization server discovery
And another one. Counting 4 now. :)
> but it just doesn't bring (in my opinion) many benefits and loses interop with existing WebDAV clients for no good reason
You just mentioned that to get to feature parity with remoteStorage, a WebDAV server needs 4 optional additions, for only one of which an unmerged PR to a single server implementation exists. Maybe I miss something, but it doesn't sound like interop is WebDAV's benefit in this scenario.
The way I read it, that's basically the point of the article.
>I'd say WebDAV is more mature, it has litmus[1] for testing implementations.
Within the first few weeks of writing vdirsyncer's testsuite, I already found a bug in SabreDAV, which is tested with litmus. I tried to raise this hole in their testsuite on their mailing list, but at the time their mailinglist was down.
>remoteStorage has as far as I know only one production instance running at 5apps [2].
Yes, that's sad. It has yet to be proven that implementations of remoteStorage will actually become more reliable than the ones for WebDAV, but I'm confident that it's easier to get implementations right with remoteStorage.
>The benefits of using the RS protocol are mostly due to the CORS headers (which could be implemented easily for WebDAV) and the use of OAuth/Bearer, for which a PR exists for SabreDAV [3].
SabreDAV implementing it is cool. They're the best FOSS serverside implementation of the -DAV protocols I know.
But still: It's all optional. Servers implementing all of this is a luxury. Right now we're in a situation where even the stuff that isn't optional doesn't work.
Don't trust anything just because it has been around for a long time.
A proper solution already exists and is called OpenID Connect (http://openid.net/connect/).
OpenID Connect solves that by extending OAuth2 with a layer to discover additional information about the authentication service (like authorization endpoint and token endpoint) and to sign up for client credentials.
There is no general issues with OAuth2 and DAV. We're using it successfully to authenticate at Google's DAV services and with Yahoo! Calendar.
There's a list compiling known bugs here: http://www.greenbytes.de/tech/webdav/webdav-redirector-list.... and here: http://www.greenbytes.de/tech/webdav/webfolder-client-list.h...
It's almost like they sabotaged the clients on purpose to break interoperability.
It turned out to be easier to write plugins for all versions of office than it was to rely on office's own code actually working.
http://sourceforge.net/p/davmail/bugs/598/
When it rains it pours.
Note that, according to some recent searching, in windows 7+, WebDAV over TLS w/Basic Auth should be less painful -- I'm going to have to test it later.
Plus each CalDAV client does things a little differently so it's very hard to debug, especially when most clients are black boxes. Permissions and feature and how they respond...a potentially different.
I (unfortunately) consider the custom CalDAV server I wrote to be a bit a technical achievement, even though I'd rather I didn't have to do it. But I had to do it because there's really no other good option for writing calendar services that work with native calendar applications.
Is there a good replacement out there?
There used to be a remoteStorage FUSE module, not sure if it still works.
Should be rather easy to implement, though. Here's the old repo: https://github.com/remotestorage/fuse
If you like Emacs, there is Tramp, and I know Vim has something equivalent.
It has been a few years since I have tried. I hope something has improved.
Again, basically, I would prefer to edit in Notepad++ or Sublime instead of vi. Personal preference.
There are a lot of complaints here that it is too complex or that it should be json rather than xml. How many people are developing their own WebDAV libraries? I like that I can grab a WebDAV library and add remote file support to my software.
It isn't perfect, but it works
My experience with WebDAV has been just that, its simplest form. Setup an Apache web server for project managers to share files with a client for example.
The state of dav clients is a mess, FWIW last I checked, getting it to work sanely on Linux, either with Gnome, or davfs -- was easy enough. Trying to get it to work reasonably from Windows was hopeless -- I never tried OS X -- I'd hoped that they actually had a usable client.
Either way, if you basically end up just being able to access it reasonably from Linux, you might as well just go with sshfs. For a handful of users, setting up reasonably secure[1], key-based file sharing -- ssh(fs) is hard to beat.
SAMBA/CIFS isn't fit to be used over the Internet, NFSv4/pNFS w/kerberos and encryption might be, but it, along with AFS is complex to set up.
The second easiest thing with some hope of being both secure and not a nightmare to get working for most (after sftp/sshfs) is probably Samba/CIFS over a VPN.
Not sure about the current state of the webdav-server/client stuff for python -- that might be a viable way to get a pair of multiplatform client/server things working. Last I looked the WebDAV part of Zope/Plone worked fine with davfs (sadly the rest of the thing, for editing content etc, needs/needed work).
On paper WebDAV har many things going for it: it works over standard TLS ports, should go through most firewalls, is "trivial" to secure using certificates (not sure about 2fa -- would probably depend on clients having a sane UI/UX for "require certificate and OTP/password" etc).
Does anyone have any experience with actually using something derived from Plan9 9p for sharing files? I've only been able to find broken, abandoned implementations, and no recent how-to's or tutorials.
Again, on paper, it would seem that 9p wrapped in some kind of certificate based protocol (either built from nacl primitives, or simply TLS/SSH) should be a reasonable candidate. A nice combination of not reinventing the wheel, and keeping things as simple as possible (as opposed to, NFSv4, CIFS, AFS).
[1] Ssh breaks down when it comes to revoking keys etc. This is in theory solved by using ssh certificates (which can expire, be revoked etc) -- but AFAIK there aren't any sane cli/ui/management tools yet. In that case managing x509 via AD or some other CA tool is probably easier -- but still ridiculously painful.
Nonsense, the reason I use WebDAV when non-tech people need a file sharing service within my company time and time again is because it works so easy on Windows and Macintosh. Their two favorite OS'.
On windows you mount it as a regular network share, you can even authenticate with AD if it's in your network. On Mac you just Cmd+K in finder and use the same URL as on Windows. On Linux I've recently learned it's equally simple.
[ed: I seem to recall I had some issues with Windows 7 as well, but I may be misremembering things. Does seem that WebDAV is now properly bundled with Windows, and https should work as long as the certificate matches. Apparently Windows will refuse basic auth (but do digest, which really isn't that much of an improvement) over standard http -- but as part of the point is the added security of simple transport encryption over SSL -- I can't imagine why anyone would want to expose WebDAV (other than read-only, perhaps) over anything other than SSL]
As for it working in OS X -- I haven't tried it -- and my impression was that it did work. Apparently others in this thread have different experiences...
I think rethinking the same problem domain with a more RESTful approach, a lot better could be done, with a lot simpler set of generic protocol extensions covering the few real gaps in HTTP/1.1 and a simple set of metadata content types [0] to cover authoring/versioning information, with primary content just using any content type.
[0] And, really, this is two problems that should be addressed somewhat separately, in terms of representation-neutral metadata content models first, and then in terms of various representations for those content models.
Of course you can show me some benchmarks that show that libxml2 is much faster than the avg. JSON implementation. But you can do that with any format that is verbose, complex and therefore hard to parse, yet has been around for so long that it paid off to write well-optimized C libraries for it.
"Yes, it's slow to fetch all events, but so is parsing XML. "
That's several orders of magnitude difference glossed over.
Ease of parsing was the whole point of XML. It was actually a beautiful concept that because it was a subset of SGML, you could validate documents and build smart editors, etc, etc on file formats in XML. Then when you wanted to simply read the file, the parser was mind blowingly simple to write.
Of course people decided that it would be great for communications protocols, and inter-language object representations and... all the stuff that it really wasn't great for.
And people decided that you would want to write event driven parsers and do DOM traversals and crazy things like that.
Yeah, that stuff is complicated. (and dare I offend people by saying that it wasn't really a good idea after all).
But parsing is dead easy. Personally prefer JSON for most things because it is easier to type :-)
Everything is trivial with a parser generator. This is besides the point.
(actually, for us at FastMail the major cost was always passing the bloody VCARDs themselves - I wound up writing https://github.com/brong/Text-VCardFast)
I've written CalDav clients. This is completely true. Being both an extension and modification of WebDAV, CalDAV cannot be used with common WebDAV libraries.
Now that we have a replacement, I'd love to see these die. Especially the latter two.
We're still missing a replacement for WebDAV though. :(
[1]: http://jmap.io/
If they considered using jCal/jCard, compatiblity would be possible and then it actually has a chance.
In fact, they could even ignore jCal/jCard and pick a format that can express the same data-model as iCalendar/vCard, and then they would still have my vote.
The way it's currently developed, is that it's an entirely new format that maps to iCalendar in a lossy way. Any iCalendar/iTip extension that is currently exists or that is under development would have no way to be expressed in Jmap.
I think the authors of Jmap have a really great understanding of Imap and what it would take to replace it, but their use-case of what they need from calendaring is narrow and their approach to replacing CalDAV is naive.
It's basically ActiveSync v2. Just like ActiveSync it uses HTTP as a tunnel with a single endpoint and an RPC-like system using POST, except ActiveSync uses WBXML, and Jmap uses Json.
They also have a proxy server that proxies client => JMAP => DAV, so if that works without a massive translation layer, it'll probably be fine.
EDIT: Just saw that you edited your post to address those points.
In that case I'd like to see a list of things that are required from a -DAV successor. JMAP's syntax strikes me as quirky, I agree, but the datamodel and the amount of methods provided seem sensible to me.
Currently CalDAV and CardDAV agents expect servers to be able to store custom properties, and retrieve those again. This is relevant for sync clients such as yours, but it becomes even more important for scheduling systems.
In addition, there's many useful efforts already existing and underway such as recursion for non-gregorian calendars, consensus-based scheduling (a la doodle), inter-server scheduling (iTip, iMip, iSchedule), Freebusy, Calendar sharing, Availability, etc that all cannot be expressed by JMap.
I'm sure there's many more issues that would cause subtle bugs. As long as people are not actually storing iCalendar and vCard, and map to their own inferior data-models (such as Jmap, but Google Calendar is another big offender), we'll continue to have interop issues.
The thing is, they don't really like jCal. It has a bit of an odd structure compared to most json formats. So my thinking is that they don't have to support jCal to work within the wider calendaring world, they just need something that maps to iCalendar in a lossless manner. They can deprecate VTIMEZONE and other frustrating features, they can introduce new properties that are easier for them to use, just don't lose compatibility.
disclaimer, I'm the main author for sabre/dav and member of CalConnect. Fwiw I DON'T think that the iCalendar format is great, but a replacement will need to have actual backwards compatibility and not just loosely model the few things that a simple online calendar such as fastmail needs.
What's wrong with storing a file inside the calendar folder? Why do clients need to do this?
Even in CalDAV/CardDAV's case: Flock had massive compat issues because no server actually supported this. So I guess it's not actually necessary?
I'm not knowledgeable enough to respond to the rest of your points. Perhaps somebody from FastMail could respond to them. But I wonder if we should simply ignore some of those feature requests to make a simple protocol for the majority of us possible.
I'm talking about iCalendar properties, parameters and components, NOT webdav properties. The distinction is important.
> Even in CalDAV/CardDAV's case: Flock had massive compat issues because no server actually supported this. So I guess it's not actually necessary?
Flock used custom 'dumb' WebDAV properties, this is not widely supported, and actually wasn't supported by sabre/dav until 3.0. Flock was the first client that required it.
Not true for iCalendar properties. CalDAV and CardDAV servers really should support it. Servers such as fastmail and google calendardon't do this well and they'll usually silently discard user-supplied data. Fastmail is part of interop the problem that we have today. They've only done this for a bit over a year, so it's not entirely surprising that their conclusion is a simpler data-model. I think most people tend to take that path before they realize the shortcomings.
Jmap and fastmail is bad for interop, and letting Fastmail pick their favourite subset of caldav and carddav and attempt to make that the standard is not really a solution, and will also probably never fly.
It wasn't clear at all what you meant.
It has caused quite a bit of trouble for CardDAV interopability, since particularly Apple has defined proprietary extensions for crucial features like groups. This lead to other clients adopting the proprietary extension, only for it to be invalidated at the next wiggle of the worm.
On collection properties, Apple has also added the color property to calendar collections. I'm sure you remember the rant on CalConnect by one of FastMail's employees about both the lack of documentation and standardization of such extensions.
Supporting arbitrary properties can be good for interop, but in DAV's case it has brought many proprietary, optional extensions whose support is almost taken for granted by the user.
EDIT: Note that I'm not for discarding unrecognized props, I'm for rejecting the whole item.
The problem here is actually the lack of vCard 4 adoption, but I agree that it's an issue. Apple (and others) have effectively extended vCard 3 to adopt vCard 4 features.
> On collection properties, Apple has also added the color property to calendar collections. I'm sure you remember the rant on CalConnect by one of FastMail's employees about both the lack of documentation and standardization of such extensions.
I also thought it was completely wrong. An extremely minor thing compared to all the things that _have_ been standardized or are currently. But there's a lot of work still to be done. Also a lot of work has been done. Work which is discarded by JMap.
> Supporting arbitrary properties can be good for interop, but in DAV's case it has brought many proprietary, optional extensions whose support is almost taken for granted by the user.
I could grant that could be an issue, but creating a standard that simply does not support any of these features out of the box is not really a solution either.
In the end, people will want to implement certain features on top of these servers because the standards don't cover the range of features of non-standard alternatives such as Lotus Notes and MS Exchange.
But I want to iterate that I agree that DAV, iCalendar and vCard each have issues, but however you look at it, JMap is a massive step backwards because it discards and ignores many years of actual standardization and development.
> EDIT: Note that I'm not for discarding unrecognized props, I'm for rejecting the whole item.
HTTP works because browsers, other clients, servers and proxies don't need to be aware of every detail of the protocol. They need to understand the overall structure and certain baserules, but if it were restricted what the response body had to look like, or which headers are legal, it would have stumped innovation.
HTML, CSS, Atom, you name them and they have a well defined-extension system and I think it's contributed to their success.
The iTip protocol needs to work like a carrier and not care about all it's contents. If in the future iSchedule lands, and we get multiple caldav servers talking together and do scheduling together, you'll want individual iSchedule nodes to ignore extensions, so that servers and clients can innovate and extend without having to alter the underlying protocol.
Have those optional extensions been that bad? I would say that they've only been bad when people have badly implemented the core protocol.
To extend the CSS analogy, it would be as if Fastmail created something similar to SASS or Less, but instead of having a 1:1 mapping, new syntax is created for every property. Well, most of them... because many CSS properties are not supported. Also, any future CSS extension would need to get explicitly added to this new stylesheet format.
I don't give a shit about my CalDAV servers talking to each other and "doing scheduling". I use WhatsApp and email for my scheduling. We don't need more features, we need less of them. CalDAV, iTip and iSchedule seem to be designed around the needs of the corporate bureaucratic world, with little to no regard to the average users' needs, and frankly, I'm horrified that for a protocol drafted in the last three years, XML is still used.
Simplicity is not just some arbitrary property I'm striving for. It's what all protocols out of the DAV series lack to be actually sensibly implementable. Have you read this thread? People are struggling to mount a simple WebDAV collection, because either the clients or the servers are so bad. And you're talking about scheduling.
This isn't even in defense of JMAP. While it at least doesn't try to add crap on top of the crappile, it's just too complex for my usecase either.
I guess I'll just stick to remoteStorage and some ics files in it.
Well that was all you needed to begin with, wasn't it? As far as I can tell your use-case could probably be satisfied by rsync alone... might be another option.
What we do need to make sure works is extensibility and custom properties, because as you have correctly pointed out - we can't tell what's necessary for the future. I really want to make the extensibility not be at the expense of the simple things working well and reliably though. I see a fetish in standards bodies for edge cases and complexity. We want "making the simple things easy and the hard things possible" not "making the hard things possible and the simple things hard". The whole user principal dance in *DAV at the end of which there is STILL no standard way to share calendars/addressbooks - all the DAV sharing stuff is basically unused or semi used, and the whole use of collections is pretty much ignoring the capabilities of DAV.... that's crazy. It's layers upon layers and you get crap like Evolution depending on seeing that the PUT action is allowed on the collection (which it's not in Cyrus, because you can only put resources with in the collection) and marking the calendar read-only. Really? Even bootstrapping is a fraught nightmare.
That's what we want to avoid with JMAP - a million choices and all of them horrible, with no clear guidance.
There were no comments yet, so it seemed ok to elaborate without destroying context.
I'm definitely with you on the issues with DAV. Things are way harder than needed.
Did anyone here try that?
By that logic it doesn't matter how bloated dataformats are.
EDIT: The big problem with WebDAV is that it's overall so complex that it's hard to implement, and XML doesn't help with that.
If you are using XML for the right applications (i.e. not a data firehose) the compression/CPU characteristics shouldn't matter at all. It's when you start using it for high bandwidth scenarios that things become sketchy: you should be negotiating an out-of-band stream (such as SI, Jingle or just a plain old socket) and using that for the firehose.
That being said, people like AeroFS supposedly used it as a firehose for years[1] (in the form of XMPP) before having to replace it with a simpler protocol: so there does seem to be some elasticity to that assertion about not using it for a firehose.
[1]: https://www.aerofs.com/blog/open-sourcing-the-stupid-simple-...
I thought HN prevents this? It seems to be the same exact URL.
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:prop>
<D:getcontenttype/>
<D:getetag/>
</D:prop>
</D:propfind>
(propfind (prop getcontenttype getetag))
{
"op": "propfind",
"prop": ["getcontenttype", "getetag"]
}
<?xml version="1.0" encoding="utf-8" ?>
<C:calendar-query xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:prop>
<D:getcontenttype/>
<D:getetag/>
</D:prop>
<C:filter>
<C:comp-filter name="VCALENDAR">
<C:comp-filter name="VEVENT">
<C:time-range start="20150909T000000Z" end="20300909T000000Z"/>
</C:comp-filter>
</C:comp-filter>
</C:filter>
</C:calendar-query>
(calendar-query
(prop getcontenttype getetag)
(filter (component "VCALENDAR")
(component "VEVENT" (time-range "2015-09-09T00:00:00Z" "2030-09-09T00:00:00Z"))))
{
"op": "calendar-query",
"prop": ["getcontenttype", "getetag"],
"filter": [
{
"component": "VCALENDAR"
},
{
"component": "VEVENT",
"filter": {
"time-range": ["2015-09-09T00:00:00Z", "2030-09-09T00:00:00Z"]
}
}
]
}
So, what does XML buy one in exchange for its lack of concision? Well, a pre-processing tool which knows nothing about WebDAV or CalDAV could use a schema definition to sanity-check the formatting of a query. It could probably be set up to detect if one used an invalid date format; it may or may not be configurable to detect if one searched for a VCALENDAR component inside a VEVENT. Regardless, there are semantic constraints in a data model which cannot be expressed with, e.g., a DTD or XSD.
How about JSON? What does it buy? Well, it has built-in hash tables (as opposed to faking them with (table (key val) (key2 val2))), which is a huge win, and it has a ton of libraries in every language one can imagine.
How about S-expressions? I think that they win on clarity, readability and concision. But there are not a ton of parsing libraries available for every language (OTOH, a canonical-S-expression parser can be written in a few hours for any language).
So, who wins? I think that for most projects nowadays, JSON's clearly the answer. The pain of XML simply doesn't pay off in practice, while the elegance of S-expressions doesn't outweigh the unfamiliarity of the great mass of enterprise software developers.
But if you have a choice, use S-expressions.
(RFC 4918: "A recipient of a WebDAV message with an XML body MUST NOT validate the XML document according to any hard-coded or dynamically-declared DTD.")
No argument—as a markup language, XML is find (not perfect, but fine); it's a better markup language than either JSON or S-expressions.
But as a data encoding, it's far inferior to JSON and S-expressions.
> See "XML Is Not S-Expressions" for a deeper treatment of the question.
Yeah, I've read it. He's right that XML is better for documents; he's wrong that the benefits of integrating data and document encoding are worth the pain of XML.
Seriously if these things bother you then and you think you have a better idea write it up in an RFC.
Writing about it this way also exposes the problems to people who otherwise wouldn't give two fucks about webdav. If the author had simply submited an RFC, only the people working on calendar/contact syncing tech would take notice.
I find it sad that you consider pointing out the flaws in something to be "whining".
A lot of the successful early internet standards followed this path. They weren't written by committee, they were written by one person with an idea to make things better.
And I only consider it whining if you point out the flaws, then don't do something about the flaws using the process for correcting them. The internet was built by the RFC process and its poorer these days because people feel to follow it is "a bit of hard work".
I only consider it whining if you point out the flaws, then don't do something about the flaws using the process for correcting them.
To even begin discussion? The discussion begins with pointing out the flaws. One person writes an article pointing out some flaws in a technology, then people comment saying how X is actually not a flaw, and how Y is also quite a major flaw. After that you start focusing on brainstorming ideas that address these flaws. Then you refine those ideas and come up with some specification or prototype implementation (followed by a specification based on it). All this has to happen before what you claim to be the beginning of the discussion.
You can do all of these things in private, maybe consulting a couple friends and colleagues, but you don't have to. You can also do it completely out in the open, on a public forum. In doing so you increase the noise, but you also increase the signal. Do you consider this process whining?