5 ms·

JMAP[1] seems to be attempting to replace IMAP + CalDAV + CardDAV. Now that we have a replacement, I'd love to see these die. Especially the latter two. We're

JMAP[1] seems to be attempting to replace IMAP + CalDAV + CardDAV. 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/ http://jmap.io/

treve 11y ago
The problem with Jmap is that it doesn't work well with the rest of the world. Unless your only use-case is personal sync, this can be problem. It's possible to ditch WebDAV, but also breaking compatibility with iCalendar and iTip makes this a no-go for most people. 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.
- untitaker_ 11y ago
  I don't know. Compatibility with jCal and jCard would've been nice, yes, but I don't think the kind of properties they support in their datamodel differ too much from what the VCard and iCalendar support. 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.
  - treve 11y ago
    Yes, the formats are inspired by standards and similar, but that's not the main point. 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.
    - untitaker_ 11y ago
      >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. 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.
      - 11y ago
- brongondwana 11y ago
  By the way, I see you edited this from the first time I read it - I should point out that FastMail provides a full CardDAV/CalDAV service and uses VCARD under the hood as well (it's the Cyrus IMAPd server) 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.
  - treve 11y ago
    > By the way, I see you edited this from the first time I read it. 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.

treve 11y ago

The problem with Jmap is that it doesn't work well with the rest of the world. Unless your only use-case is personal sync, this can be problem. It's possible to ditch WebDAV, but also breaking compatibility with iCalendar and iTip makes this a no-go for most people. 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.

untitaker_ 11y ago
I don't know. Compatibility with jCal and jCard would've been nice, yes, but I don't think the kind of properties they support in their datamodel differ too much from what the VCard and iCalendar support. 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.
- treve 11y ago
  Yes, the formats are inspired by standards and similar, but that's not the main point. 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.
  - untitaker_ 11y ago
    >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. 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.
    - 11y ago
brongondwana 11y ago
By the way, I see you edited this from the first time I read it - I should point out that FastMail provides a full CardDAV/CalDAV service and uses VCARD under the hood as well (it's the Cyrus IMAPd server) 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.
- treve 11y ago
  > By the way, I see you edited this from the first time I read it. 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.