4 ms·
TL;DR A bag of neatly unified transport hacks around X-Domain restrictions. Like Socket.io, but without the proxy server and direct connect instead of pub/sub.
by Animus7 15y ago
TL;DR
A bag of neatly unified transport hacks around X-Domain restrictions. Like Socket.io, but without the proxy server and direct connect instead of pub/sub.
- jacobolus 15y agoIncorrect. This library is for communication between two browser frames or windows. Socket.io and other Comet servers are for communication between a browser client and a server (sometimes these Comet servers use some kind of communication channel between frames on different domains as part of their internal machinery, but that’s just an implementation detail).
- Animus7 15y agoI think we're both correct here. Blasting data between frames to get around cross-domain restrictions is a means to an end. What you're really trying to achieve is data moving between hosts at different domains: i.e. pushing or pulling. In that sense both this and Socket.io are trying to achieve the same thing, only EasyXDM is more free-form about it. Though I do admit I haven't used EasyXDM myself so I could be totally confused. The repo documentation is long and vague, hence my TL;DR.
- jacobolus 15y agoAs a comment elsewhere in this discussion says (it really should be voted up to the top), EasyXDM is just a wrapper for the HTML5 postmessage API, with fall-backs in browsers which don’t support it. * * * > What you're really trying to achieve is data moving between hosts at different domains Not really. Usually when you use something like EasyXDM, the goal is either to build a site that has different server components located on different domains under your control, or to build a mashup between services explicitly set up to be used for mashups. There’s no data being “moved between hosts”; we’re just combining two data sources in one browser window. When you use a Comet server like socket.io, by contrast, the goal instead is to open up a persistent connection between browser and server, so that data can be sent back and forth. Also, FWIW, there’s nothing in socket.io or most Comet servers that forces a developer to implement a pub/sub system, as you implied in your first post. [As I said before, sending cross-domain messages between frames, e.g. using EasyXDM, might be part of the inner workings of the browser side of some Comet transports, but that’s just an implementation detail, and an application developer would not be expected to touch that code or care about it; it’s just a black box.] Neither one of these really matches your description, and the two are substantially different from each other. I think you’re confused.