|
IWCProjects
List of system that enable inter-window or web worker communication
Featured This page will not be actively maintained. However, we have published a paper about the classification framework for cross-context communication in Web browsers together with a broad evaluation of existing systems. The paper presents a more detailed and advanced analysis of cross-context communication than the one addressed in this wiki page. You can find the paper here. --- --- --- --- This is an overview of systems that enable communication between different contexts or web workers running in the browser. The overview includes systems that enable program A executing in the browser to send data to program B also executing in the browser and enable program B to receive the sent data. Programs A and B must be web applications executing in different browsing context (windows, iFrames) or web workers. This problem of web applications development is not new and lots of systems have been researched and built with the purpose of solving it. Therefore, let us know (in the comments of this page) if we didn't list a system you know of or if we mis-categorized a listed system. Also, some relevant systems that are either insufficiently described, not implemented (research concept) or archaic were left out from the overview but are listed at the end, with references. Below is also a list of other articles that surveyed or analyzed this type of communication. Each system is categorized based on the following criteria:
Acknowledgments :
Related work, security considerations and existing systematizations
References [1] A. Barth, HTTP State Management Mechanism, IETF Internet-Draft. Link [2] I. Hickson, HTML5 - Section 5 Loading Web pages, subsection 5.2 The Window object, subsection 5.2.1 Security, W3C draft. Link. C. Jackson, H. J. Wang, Subspace: Secure CrossDomain Communication for Web Mashups. Link. [3] J. Lecomte, Introducing CrossFrame, a Safe Communication Mechanism Across Documents and Across Domains. Link. [4] I. Zuzak, M. Ivankovic, The pmrpc library homepage. Link. [5] S. Kinsey, The easyXDM framework homepage. Link. [6] Apache Shindig RPC feature source code. Link. [7] Apache Shinding PUBSUB feature source code. Link. [8] The open-app project homepage. Link. [9] I. Hickson, HTML5, Cross document messaging. Link. [10] I. Hickson, HTML5, Channel messaging Link. [11] I. Hickson, WebStorage, W3C draft. Link. [12] I Hickson, Web SQL Database, W3C draft. Link. [13] Apache Shindig, RMR transport implementation. Link. [14] Apache Shindig, NIX transport implementation. Link. [15] Apache Shindig, FrameElement transport implementation. Link. [16] Postmessage jQuery plugin homepage. Link. [17] xssinterface project homepage. Link. [18] jQuery postmessage plugin homepage. Link. [19] jquery hive plugin homepage. Link. [20] I. Hickson, Web Workers, WHATWG draft. Link. [21] OpenAjax Hub Specification 2.0. Link. OpenAjax Alliance implementation of OpenAjax Hub 2.0 Link. [22] F. De Keukelaere, S. Bhola, M. Steiner, S. Chari, S. Yoshihama, SMash: Secure Cross-Domain Mashups on Unmodified Browsers. Link. [23] Google Wave gadgets tutorial - Gadget state. Link. [24] T. Nelkner, An Infrastructure for Intercommunication Between Widgets in Personal Learning Environments. Link. [25] S. Wilson, P. Sharples, D. Griffiths, Distributing education services to personal and institutional systems using widgets. Link. [26] E. Mullins, Local Connection Actionscript – Communicate between seperate Flash files. Link. Adobe Support, An example of communication between JavaScript and Adobe Flash Player. Link. Adobe support, LocalConnection. Link. [27] (patent) H. Schneider, Communication between browser windows. Link. [28] (patent) J. C. Everett-Church, Communication among browser windows Link. [29] (patent) A. J. Simonoff, Interactive communication system permitting increased collaboration between users. Link. [30] (patent) G. Clayton, V. Chen, A. Athsani, R. Martinez, System and method of inter-widget communication. Link. [31] (patent) G. Corvera G. Moore D. Thorpe K. Kato, Inter-frame messaginf between different domains. Link. [32] S. Zarandioon, D. Yao, V. Ganapathy, OMOS: A Framework for Secure Communication in Mashup Applications. Link. [33] K. Zyp, http://www.sitepen.com/blog/2008/07/22/windowname-transport/. Link. [34] Window.name transport implementation in easyXDM framework. Link. [35] C. Jackson, H. J. Wang, Subspace: Secure Cross-Domain Communication for Web Mashups. Link. [36] L. Hilaiel, jsChannel. Link. [37] P. Kinlan, Web intents. Link. |
easyXDM: cross-origin | no | window.name, FIM, postMessage | message oriented, exposes RPC API, not yet (exposes the origin) | yes | async | push
easyXDM isn't really 'server mediated' as it does not communicate with the server. It only requests a file (a special html file for window.name, and any url for FIM), which due to aggressive caching should only need be retrieved on the first request. This is in turn only to facilitate 'client-client' communication.
The reference you have used for Window name attribute 33? isn't really in-browser as it is based on communication with the server.
@okinsey: You're right. However, it does explain the mechanics of passing data unidirectionally between a window which creates another window, using the window.name parameter. I'll be glad to replace the current reference if you have a better one. Thanks!
Well JMS is working at the server-level but can also push data (or be polled) with an AJAX client, or, any other combination of a server-side and one of the above systems...
JMS | in-browser and desktop | cross-origin | cross browser and cross-os instance (for desktop) | general purpose | yes | yes | (RESTful) HTTP or STOMP (TCP) | Topics (publish-subscribe) OR Queues (transactional) | yes | yes | all Topic-based pub/sub may expose data to all listening application instances (unless other encryption/filters or Broker-specific transport controls are applied) | JMS product/spec: http://java.sun.com/products/jms/ Apache ActiveMQ (popular implementation): http://activemq.apache.org/ | " unlimited... Max 70MB by default, but protocol should be limited only by implementation/server supports encrypted/signed messages... | Implementation-specific; spec speficies support for reliable message transfer | In-message, or, in the Broker connection management itself | In-message, or, in the Broker connection management itself | depends on chosen protocol/broker | depends on chosen protocol/broker