Hi all,
If you're keeping an eye on the JMAP Spec repository[1] over the last
few days, you'll notice there have been a few changes. Here's an outline
of what's new, and what's upcoming:
The main change is that JMAP has now been split into 4 specs: the core
protocol[2], mail[3], contacts[4], and calendars[5]. There are a few
reasons for this:
* Not all implementors need the different data types. It's easier (and
better for compatibility) to be able to say you fully implement 2
specific specs (say), rather than part of 1 spec.
* The core + mail parts are probably more stable than the
contacts/calendars. The intention for the latter too is to use the
JSON object formats being standardised by the CalConnect[6]
consortium to represent events and contacts. The event object has
therefore changed quite a lot over the last few months (but should be
fairly stable now); the contact object may still need to change.
* Most of the current implementation activity is focussed on core +
mail, and we want to be able to get these finalised without having
to have necessarily finalised the contacts/calendars part due to
the above.
* It means future datatypes that may be added in the future are on
the same level as mail, calendars or contacts rather than second-
class types.
Because of the split, I've removed the previous versioning mechanism
(which used to be JMAP version + vendor extensions versions). We need
something here, but I'm not sure what the best approach is.
Suggestions welcome!
Here's a quick summary of the other changes that have been made over the
last two weeks (there were also various fixes for minor copy-paste
errors etc.):
*Core*
* Information about accounts is now returned with the authentication
information rather than via a getAccounts call. This feels a more
logical place for it. The getAccounts method was always a bit odd, as
it was really related to your authentication, whereas all the other
data *belongs* to an account.
* Capabilities are now also returned with the authentication
information, separately to the accounts. Capabilities belong to the
server, not the account.
* The maxChanges argument to getFooUpdates MUST be respected by the
server. This is so the client is always in control of how much data
it's going to receive back over the network.
* A number of changes have been made to ensure the server can
reasonably restrict the client from overloading it (either
accidentally or on purpose as a DOS attack), including:
* A new HTTP error code (413) may be returned by the server if the
client makes a request that's larger than it wants to process.
* An error can be returned if an individual method call asks the
server to fetch too many objects, or make changes to too many
objects (and the limits can be discovered by the client in the
server capabilities information).
* The cannotCalculateChanges error no longer returns the new state
string. It's not actually very useful to the client, and it might be
hard for some servers to calculate.
*Mail*
* Servers SHOULD now disallow mailboxes with duplicate names at the
same level. This was for compatibility with the requirements on most
existing servers.
* A cannotDoFilter error may now be returned if the client sends the
server a message list request with a filter that's too complex, or
can't be processed for whatever reason.
* The client must now always specify the sort directions in a message
list. The implicit "descending" is surprising to some implementors,
and the JMAP philosophy is generally to be explicit. Saving a few
bytes here is negligible.
Oh yeh, and the final change: because it's not just about mail and
hasn't been for some time, JMAP now stands for *JSON Meta Application
Protocol*. :)
Cheers,
Neil.
Links:
1. https://github.com/jmapio/jmap
2. http://jmap.io/spec-core.html
3. http://jmap.io/spec-mail.html
4. http://jmap.io/spec-contacts.html
5. http://jmap.io/spec-calendars.html
6. http://calconnect.org
--
You received this message because you are subscribed to the Google Groups
"JMAP" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jmap-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to jmap-discuss@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jmap-discuss/1476759408.3357511.759142657.69866762%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.
