Forgive me for not being very literate with this type of development, but why would you use Bridge over something like ZeroMQ? (I don't work much in this area, so sorry for my naïveté.)
ZeroMQ is one layer down the stack. It is higher-level than TCP but it's basically a transport.
Bridge comes with RPC and automatic routing. It allows you to expose services simply by instantiating native objects and making method calls. (Like an easier version of Apache Thrift: http://thrift.apache.org/)
It also takes care of the socket management and routing for you, so there is no host/port configuration to talk to any endpoint in the system. You can simply address things by a human-readable name like "photo-processor" or "search-server".
That's cute, but the server is actually at getbridge.com, it's not IE6. A browser cannot serve requests. The IE6 client is communicating via getbridge.com, from where the actual connections are being served. There's just some centralized application code in that particular IE6 browser that is controlling the channel logic.
This is pointed out explicitly in the section titled "Is this magic?"
We never claim "no server." Our goal was to ask the question, what's possible if you can run computational logic in the browser and rely on a physical server purely for message routing (Bridge).
Yeah, this is no more than a glorified chatbot - and an inefficient one, too, if it's IE6. Although Pusher requires a real server to publish, AFAIK, Pubnub allows clients hosted on static pages to publish just fine. Bridge is just a very nice syntax. But that's OK... if it makes the web more realtime, I'm all for it.
The JavaScript in IE6 isn't too horrible. It's mostly the layout and rendering that it sucks at. By choosing IE6, they could give you the scares without really having a lot of trouble.
I bet they made it with Chrome (or the likes), copied it into IE6, fixed a bug or two (without even bothering about cross-browser compat), and done. 30 minutes. Writing the article costs more time.
While this is awesome, I think declaring the "death of client-server" is kind of naive. For anything that handles sensitive information (e.g. the auth() service here), it'd be mayhem to have all clients also be servers.
Our interpretation is that the concept of a client and a server is no longer relevant. Clients are just machines that are over the network that you don't trust. An iPhone is more powerful than servers from 10 years ago. It's a (bad) brief explanation but do you see my point?
Perhaps the only relevant concept now is publishers and subscribers rather than clients and servers?
[+] [-] possibilistic|13 years ago|reply
[+] [-] sthatipamala|13 years ago|reply
Bridge comes with RPC and automatic routing. It allows you to expose services simply by instantiating native objects and making method calls. (Like an easier version of Apache Thrift: http://thrift.apache.org/)
It also takes care of the socket management and routing for you, so there is no host/port configuration to talk to any endpoint in the system. You can simply address things by a human-readable name like "photo-processor" or "search-server".
[+] [-] btipling|13 years ago|reply
[+] [-] dshankar|13 years ago|reply
We never claim "no server." Our goal was to ask the question, what's possible if you can run computational logic in the browser and rely on a physical server purely for message routing (Bridge).
[+] [-] btown|13 years ago|reply
[+] [-] ciparis|13 years ago|reply
[+] [-] skrebbel|13 years ago|reply
I bet they made it with Chrome (or the likes), copied it into IE6, fixed a bug or two (without even bothering about cross-browser compat), and done. 30 minutes. Writing the article costs more time.
[+] [-] rgarcia|13 years ago|reply
[+] [-] dshankar|13 years ago|reply
Perhaps the only relevant concept now is publishers and subscribers rather than clients and servers?
[+] [-] jtchang|13 years ago|reply
[+] [-] sukuriant|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] drhowarddrfine|13 years ago|reply
[deleted]