/* Copyright (c) 2004-2006, The Dojo Foundation All Rights Reserved. Licensed under the Academic Free License version 2.1 or above OR the modified BSD license. For more information on Dojo licensing, see: http://dojotoolkit.org/community/licensing.shtml */ dojo.provide("dojo.io.common"); dojo.require("dojo.string"); dojo.require("dojo.lang.extras"); /****************************************************************************** * Notes about dojo.io design: * * The dojo.io.* package has the unenviable task of making a lot of different * types of I/O feel natural, despite a universal lack of good (or even * reasonable!) I/O capability in the host environment. So lets pin this down * a little bit further. * * Rhino: * perhaps the best situation anywhere. Access to Java classes allows you * to do anything one might want in terms of I/O, both synchronously and * async. Can open TCP sockets and perform low-latency client/server * interactions. HTTP transport is available through Java HTTP client and * server classes. Wish it were always this easy. * * xpcshell: * XPCOM for I/O. * * spidermonkey: * S.O.L. * * Browsers: * Browsers generally do not provide any useable filesystem access. We are * therefore limited to HTTP for moving information to and from Dojo * instances living in a browser. * * XMLHTTP: * Sync or async, allows reading of arbitrary text files (including * JS, which can then be eval()'d), writing requires server * cooperation and is limited to HTTP mechanisms (POST and GET). * *