2 ms·

I hope not, because it's hard to blame only Erlang. First of all, they rolled their own epoll-based server for the whole chat system. Then, instead of using a

I hope not, because it's hard to blame only Erlang. First of all, they rolled their own epoll-based server for the whole chat system. Then, instead of using a 'sane' comet/long-poll implementation based on JSONP (to avoid limitations of same-domain requests), it seems that they used a scheme where the chat nodes have a fake subdomain like 'http://N.subdomain.facebook.com/... http://N.subdomain.facebook.com/.... I don't know how efficient this is supposed to be, but I haven't seen that too often. Of course, it's wholly possible their Erlang implementation of the chat system is the reason why it fails. Personally, I have never had much trouble with their chat, although I haven't used it much either.

lukatmyshu 17y ago
The reason that they use N.subdomain.facebook.com is so they can avoid the default "2 http requests per domain" rule in older browsers.
- mononcqc 17y ago
  I know that. What I don't get is why they chose that over JSONP, which solves the exact same problem by using <script> tags and a callback function. Their solution seems to work well, anyway.
  - catch23 17y ago
    The jsonp method causes older browsers to use a ton of memory if you leave the browser window open for a long period of time. You'll see that there's a whole bunch of script tags in the dom that aren't cleaned up. Given the way people use facebook & how many old browsers still exist, this is probably the reason facebook decided against it.
    - axod 17y ago
      jsonp also causes unsightly "loading" indicators in most browsers.
  - lukatmyshu 17y ago
    Plus w/ jsonp can't get the response from POST requests and you don't get notification that your page didn't load. So your web-stack needs to be able to handle sending any errors via jsonp as well. In any case, they don't solve the same problem. Jsonp solves the problem of talking to another domain (PostMessage does the same thing). Channels solve the problem of the browser limiting the number of concurrent HTTP requests you can have open to one domain.

lukatmyshu 17y ago

The reason that they use N.subdomain.facebook.com is so they can avoid the default "2 http requests per domain" rule in older browsers.

mononcqc 17y ago
I know that. What I don't get is why they chose that over JSONP, which solves the exact same problem by using <script> tags and a callback function. Their solution seems to work well, anyway.
- catch23 17y ago
  The jsonp method causes older browsers to use a ton of memory if you leave the browser window open for a long period of time. You'll see that there's a whole bunch of script tags in the dom that aren't cleaned up. Given the way people use facebook & how many old browsers still exist, this is probably the reason facebook decided against it.
  - axod 17y ago
    jsonp also causes unsightly "loading" indicators in most browsers.
- lukatmyshu 17y ago
  Plus w/ jsonp can't get the response from POST requests and you don't get notification that your page didn't load. So your web-stack needs to be able to handle sending any errors via jsonp as well. In any case, they don't solve the same problem. Jsonp solves the problem of talking to another domain (PostMessage does the same thing). Channels solve the problem of the browser limiting the number of concurrent HTTP requests you can have open to one domain.