nmjenkins

Well, Overture was created several years before React came along (it actually predates Angular and Ember as well), so it would have been hard to make it as plugins to this! It's not actually as monolithic as it first appears: a small change to the build tool could easily let you just build the parts you want (e.g. just the view system, or just the datastore). Each folder inside the source/Overture/ directory is really a separate module. The dependency information between the modules is already in the files so that the build tool orders them correctly, so it would be a small extension to make it only include the modules you want + dependencies.

Basically, the library is perfect for us (and we think it's pretty neat; our web app is one of the largest, most complex and fastest out there, and the codebase is very clean). But we totally understand that the lack of more documentation, examples (or even books, tutorials and seminars!) compared to the popular libraries makes it harder for people to get into. We still wanted to put the code out there in case someone found it useful, even if only as inspiration rather than using it directly.

If you want to see an example of idiomatic Overture usage, take a look at the source of the JMAP demo webmail. It's fewer than 2000 lines of non-library code, and yet packs a lot in!

You have to be a high volume sender with a good reputation (low spam reports) to get access to these tools.

What I don't get is, why did they dismiss the plans out of hand 200 years ago when the guy that wrote them was literally famous for producing a revolutionary clock? I mean, with that kind of track record, you'd have thought someone would give it a go.

Each call is tagged by the client and the same tag is added to the response by the server, so you can tell exactly what error corresponds to which call.

Caching is pretty easy: you just keep a cache of each object type. The delta update mechanism means you can very accurately invalidate what you need to keep it up to date. The system is actually really flexible and a great fit for any CRUD based app; JMAP is really just a combination of a very powerful and efficient database access protocol, and the definition of some objects to represent email, contacts and calendars.

So you're assuming that an independent encryption layer that has to be reimplemented by every email client dev is going to be more secure than a widely studied protocol, implemented at the OS level. Right…

I presume you mean extending native prototypes? If you're in complete control of the code in your page there's no problem doing this and it makes some code much neater and more readable. The only other global is "O", which is the namespace object for the library.

Yes. Everything is a single codebase, desktop and mobile, and it's all powered by Overture.

As mentioned in the article, the core object system was inspired by SproutCore (4 years ago), which was in turn inspired by Cocoa, so yes there is a heritage. However, Overture is designed to enhance web tech rather than turn it into something else (which was always the impression I got with SproutCore).

If you have a way of reproducing this, please file a support ticket. We've not come across this issue so far. Thanks.

It does support this. The demo being linked to is not a particularly great integration and using an out of date version of Squire. Try it in FastMail.

iOS supports CalDAV natively. Just follow the instructions at https://www.fastmail.com/help/clients/iphone.html (scroll down for calendar section).

I disagree. Voting is a responsibility, hard won through history and still not a privilege available in all countries. As pointed out by the parent post you absolutely do not have to agree with any of the options. 50% of the population spoiling their ballot paper would be a massive statement and precipitate political upheaval. 50% of the population not bothering to show up just says they don't care.

FastMail has conversations, keyboard controls and decent search, with both webmail and calendar and is $40/year for a 15GB account…

(Disclaimer: I work for FastMail. But seriously, it sounds like we might be just what you're looking for).

Do you have CSRF protection on login? If not, an attacker can add an XSS attack to their own account, then log the victim into the attacker's account by submitting a cross-site post request with their username and password. This could potentially then read data from any other accounts the victim is logged in to at the same time. If you don't support multiple simultaneous logins, it could still allow the attacker to generate a phishing page, at your URL, which sent them back any data the user entered.

You can host up to 50 domains (with up to 500 addresses) for $40/year with a FastMail Enhanced account (all delivered to the same mailbox).

Umm, we're actually in Melbourne, Australia (I work for FastMail).

Lucky I'm not considering adding it to either POP or IMAP then. :)

(Author of the spec here)

We will be adding sending to the JMAP spec, although support may be optional. The way it currently works at FastMail is a bit too specific to our architecture though, so we want to clean it up before adding it to the spec.

(Author of the spec here)

REST is way too slow. The JMAP format massively reduces round trip times, especially when you have sequential operations where you must wait for one to finish before the next can happen. And once you're not doing REST, I don't personally think putting HTTP verbs in the method calls doesn't really make it any clearer, and is just likely to confuse matters.

No. See my answer to jorangreef above, but essentially this protocol is for server <-> client sync, but you can still do efficient server <-> server sync for distributed backends.

(Author of the spec here)

The protocol could just as easily go over a WebSocket as HTTP (you'd have to change authentication mechanism, but that would be trivial). The only reason we don't do that at the moment is: 1. Browser support (we support back to IE8, unfortunately) 2. Lack of GZIP compression (particularly of responses from the server); this was being worked on last time I looked, but I haven't checked recently to see if it's been implemented yet. This is crucial for saving bandwidth.

That would get rid of your HTTP overhead; I will put some mention of that in the spec (I think HTTP support should be required, and WebSocket support optional).

As for JSON vs. binary: * There are libraries to use JSON everywhere – binary protocols would require everyone to implement another parser, adding extra difficulty for adoption and a surefire source of bugs. * JSON is readable over the wire, binary is not. Trust me, in the real world, this is a huge advantage for debugging all sorts of things. * JSON can be used trivially in a web app. Apparently this World Wide Web thing might catch on. * The parsing overhead of JSON is not too large; yes it's longer than a binary protocol, but it hasn't been a bottleneck for us, even on mobile.

(Author of the spec here)

A fixed-size Merkle tree is a great idea if we wanted to sync the entire set of messages between distributed MX destinations. In fact, we should probably consider that approach for our server <-> server replication. However, JMAP is aimed at client <-> server sync. There are a number of different issues to consider here. The client may have limited or no cache (a webmail app for instance must normally start anew each time, and needs to efficiently fetch just what it needs; if we had to wait for a 60GB mailbox to sync every time we loaded our webmail, well, obviously that's not going to work. A mobile mail client often only wants to download the first few items in the mailbox given the current sort order so it can display them to the client. The JMAP spec allows a client to download, say, just the list of the first 50 messages, newest first, in the Inbox (single round trip). Then, at a later point, it can ask for and receive a space-efficient delta update of what has changed within those first 50 messages in the Inbox, regardless of how big the Inbox really is, or what other messages may have been delivered elsewhere (including lower down the Inbox, but outside the top 50). Again in a single round trip. This is really powerful: you can see that by comparing the refresh time of a folder in the FastMail mobile web app with the iOS or Android native mail app (over IMAP); the mobile web app is much quicker.

The other thing to remember is that the metadata about the message is mutable, and needs to be kept in sync as well. Again, the modseq system described in JMAP allows this to happen efficiently. If you have a distributed server system with multiple masters, you will again use a different system to keep those in sync (as they each assign new modseqs, whereas the client does not). However, this too can be dealt with relatively easily: if the modseq for a message differs between two masters, it must be set on both to max(the higher of the two modseqs, the next highest global modseq on the server with the currently lower modseq). This will ensure that both will end up in the same state, and that the client will get refresh its state for that message if it has to, no matter which master it last synced with.

So essentially, there's a difference in what you want in a protocol for server <-> server synchronisation for distributed mail backends compared to client <-> server sync for mail apps. JMAP is focussed on the latter, but tries to make sure it doesn't include assumptions that severely limit the former. The spec does not require a particular format of message ids: they do not have to be based around IMAP's ascending UIDs (although the sync algorithm for partial mailbox listings may be slightly less efficient if not).

We probably will publish this as well. We're focussing on the core API first. Having said that, it's really very simple. Here's the entirety of our (currently internal) spec for push events at FM:

This is a text/event-stream resource, as described in [http://www.w3.org/TR/eventsource/](). The following events are pushed:

- progress: Sent during a long-running api method call to let the client know not to timeout the connection. The data is a JSON object with a single property: `connectionId`, with the id the client sent for that connection. This event does not set a new id in the event source stream.

- push: Sent whenever the user's highest modseq changes. The event id is the new highest modseq. The data for the event is a JSON object, with the following properties:

  * **clientId**: `String` (optional). If the change was due to an action initiated by
    the API, the `X-ME-ClientId` header will be echoed back as this property. This
    allows clients to ignore push events for changes they themselves have made.

  * **mailModSeq**: `Number` (The highest modseq for a mailbox)

  * **contactsModSeq**: `Number` (The highest modseq for contacts/contact groups)

  * **calendarModSeq**: `Number` (The highest modseq for calendar events).

One of the main efficiency gains is in massively reducing the number of round trips required to do a series of operations. This batching of operations is hugely important on high-latency connections, relevant for us in Australia all the time but also of importance on mobile connections the world over. Even 4G networks have relatively high latency, but can do a burst transfer pretty efficiently.

You should check out https://pin.net.au/ – it's an Australian competitor to Stripe. You can accept payments in USD and Pin will settle in USD to an Australian account (this is exactly what we do at FastMail). We've been using them exclusively for the last few months and are pretty happy, other than the lack of Amex support, which they're still working on.

Nonsense. FastMail's webmail allows you to scroll continuously through (or jump to any section of) your mailbox, even when they have 100,000+ messages in them. (Disclaimer: I work for FastMail). This is not an inherent limitation of the underlying technology, just one of implementation.

Huh? 1GB is $20/year, 15GB is $40/year – https://www.fastmail.fm/signup/personal.html

Pretty much everything in FastMail can be done with a keyboard shortcut as well: http://fastmail.wikia.com/wiki/KeyboardShortcuts. It's "m" instead of "v" for move, but other than that, most shortcuts are the same as for GMail.

(I work for FastMail) Many apologies about this. It was due to an unexpected interaction with our billing system when we added the free trial functionality. We never intended to spam or harass people who decided FastMail wasn't for them. We fixed this about a month ago and overhauled the wording in our notices as well to make them friendlier and easier to understand.

I work for FastMail. We (Opera Software Australia) are an Australian company, subject to Australian privacy laws regardless of the location of our servers. We legally must only respond to Australian law enforcement agencies with valid Australian warrants (summary of the law is available here: https://www.efa.org.au/Issues/Privacy/tia.html).