Which part of what?

I don’t understand your answer, that’s basically what wmf described. Put a proxy or load balancer in front of your service.

Thanks. I can't upgrade clients to add reconnect functionality, and I can only work on the server side to solve the scaling issue. I think I should refactor my service as you mentioned by separating dedicated connection-managing servers and stateless worker servers such that I can scale workers.

> I think I should refactor my service as you mentioned by separating dedicated connection-managing servers and stateless worker servers such that I can scale workers.

thats exactly what the original suggestion seemed to be was.

Yupp. I think I misunderstood at first. Now I get it. Thanks all.

I don't like the idea of not having my development certificates under control. They should be as secure as the production certs in my opinion. I use PHPKi for that purpose, it's not pretty but easy to setup and it runs in my own environment.

I used this font since more than a year. It's great but a week ago I started using Source Code Pro.

How can I remove a project?

Yes - you'll need to login at mailflo.io. We haven't added that functionality to the browser extension. Do note that deleting a project would not delete the associated emails and labels.

Just email us at support@mailflo.io if you need help.

Thanks!

Have a look at AWS OpsWorks.

I also strongly disagree. The real problem is that browsers can't use them as good as they should. If you take for example a RESTful API, the verbs make totally sense and especially one of the mentioned verbs. PATCH is a great verbs if you use it like it was specified. I personally like the idea of giving more freedom to chose the verbs. Imagine you could use for a Twitter API something like: FOLLOW /users/123

> The real problem is that browsers can't use them as good as they should

That's the obvious inevitability of having too many superfluous options. And one of the main thrusts of the article.

Yes, but people disagree on the "superfluous" part.

Yes, it would be horrible if you instead had to do: POST /user/123/follow

PUT /myuser/following/theiruser

PUT /user/123 { id: 123, following: { foo, bar, baz } }

  PUT /user/123/following

    /user/foo
    /user/bar
    http://www.other-site-using-standard-formats.com/user/baz

Sigh, if only.

Yeah, if that's where your URL ended. But what if your URLs kept going? Say you had

    /user/123/followers

or

    /user/123/followers/followers

or

    /user/123/followers/followers/following

? When your URLs have a non-obvious terminus (as is typical of proper REST APIs) it becomes clear that the verb does not belong in the URL path.

So you're saying that we should have a verb instead?

FOLLOWERS_FOLLOWERS_FOLLOWING /user/123

No, the verb is FOLLOW, as in the example you were responding to:

    FOLLOW /user/123/followers/followers/following

The HTTP specification in no way restricts the verbs that you can use to those that are in common use. But at some point somebody, somewhere, decided that the only ones allowed were the ones that the specification explicitly mentioned. And so people just shoehorn their applications into frameworks built around what the HTTP specification defines, rather than allows.

Ain't nobody got time for defining semantics.

Javascript can use them just fine. Browsers without JS can't do a lot of useful things, that's why JS exists.

ssl is handled on app basis not in the load balancer and by the way, you can hook into everything by rewriting or overwriting the recipes

That's what I figured. It seems odd that they'd be enforcing that approach from the start, though

But OpsWorks is the answer for the problem.