X3D Networking
Charter Document
Chairs: Chris Thorne*, Leonard Daly
last updated: 19 February 07
Web3D Consortium X3D Network Working Group
Charter Document
Chairs: Chris Thorne*, Leonard Daly
Last updated: 11 April 07
Update History:
| Date | Reason |
|---|---|
| 11 April 07 | Formating and minor English changes |
| 22 February 07 | Original Approved Document |
1. Overview
If X3D standard is to become part of the everyday Web we should listen to the lessons from those who wrote the standards that form the backbone of the Web today. One of those lessons is written into the W3C's Architecture of the World Wide Web, Volume One:
- Protocols designed to be resilient in the face of widely varying environments have helped the Web scale and have facilitated communication across multiple trust boundaries. Traditional application programming interfaces (APIs) do not always take these constraints into account, nor should they be required to. One effect of protocol-based design is that the technology shared among agents often lasts longer than the agents themselves.
The above quote shows the W3C has learned from long experience that protocol standards form a sound foundation for Web applications. As the quote also indicates, APIs are less suited for forming a lasting backbone. Any Web application of significance needs to support the same network standards in order to be effective as a multiuser application connecting users to each other, to external components and to Web services. A major goal of X3D is to support 3D web applications, in addition to 3D on local networks and local machines, so it's ability to make use of network standards with portability and without significant difficulty is of paramount importance.
In 1994 Pesce et al [10] proposed a client-server cyberspace protocol which required new protocol support and modified DNS resolution for its multiple domain field. The proposal did not succeed and no other protocol proposals have been considered for adoption into the Web3D standards. Instead, there have been many ad-hoc attempts at implementing multiuser systems that also connect clients to external components and servers for persistent data and services. None of these attempts have succeeded to gain much traction because they tried to implement the essential connection capabilities within the client environment. The client environment (Web browsers, programming APIs, and, mostly, Windows operating system) kept changing as different industry stakeholders fought over commercial and technical interests. Generally, these attempts used the EAI (or SAI) and one or more layers of API or script interfaces. The resilient standards protocol framework was not there and client environment changes could severely restrict or even break networked multiuser and external interfacing applications. For those who wish a more detailed history about implementing the networked communications in Web3D applications, please refer to the history part of [8].
This charter is designed to provide an efficient, flexible and robust means for distributed application components and applications to inter-operate through improved networking capability. It also aims to be easy for content developers to use. This charter aims to establish a strategic protocol foundation for X3D applications similar to that of the Web today by supporting the most common internet protocols in the X3D specification as a cross platform aspect.
As illustrated by the portion marked in green in Figure 1, we propose to support a strong external communication capability, by going directly to the network from the Web3D Browser. This is complementary to the existing Web browser API based architecture for external communication capability (external SAI), not a competing approach.
In looking how we can make it easy for content developers to use, one of the proposals put forward is an X3DNetworkSensorNode proposal [4,5].
2. Discussion
From Figure 1, it can be seen that the current external communication capability is file/stream I/O and limited HTTP.
Figure 1: Conceptual architecture of an X3D browser showing external interfacing communication. The current network communication capability is limited to file I/O and a limited HTTP implementation. The part blocked out in green represents the strong networking capability proposed by this document.
The latter is dented "limited" because it is based only on the HTTP "GET" request, there is no security support and the HTTP protocol and URL formatting is only used for the outgoing request: the return format must be X3D. Apart from the HTTP "GET" request, there is no way for a content developer to make use of other commands like MGET, POST or HEADER. The return path restriction is also unsuitable for a general network communication capability where there is a need to communicate with applications other than X3D applications.
For X3D to inter-operate with other standards, such as XMPP and applications from other significant groups, such as OGC, the network interface needs to support full HTTP, TCP/IP, UDP and secure versions thereof. Such an interface will greatly aid collaborative efforts with other open source and open standards organisations.
As can be seen from Figure 1, this charter assumes a node level approach, based purely on the current proposal, but other proposals can be put up for review. The node approach makes it easier for content developer and authoring tools to use networking with limited scripting, if any, required. The charter also embodies the concept that events should be able to route between nodes or over a network transparently: without any changes to the current routing mechanism.
For further information and discussion, please refer to the current proposed amendments: [4].
3.
How this proposal relates to other approaches using existing technology with existing X3D specification
Since this proposal provides a network approach to integrate distributed application components or applications, it is worth comparing with alternative ways to achieve this end using current capabilities. There are three main approaches that can be used together or separately (i.e. They are not mutually exclusive), including the direct networking one (this proposal).
3.1. Web browser supported javascript approach
This is a layered approach as is utilises the SAI to interface with javascript and perhaps java or the DOM in order to pass information between the 3D world and some external component/application, typically a server based set of services or database. This approach includes the group of methods called AJAX. For this approach network communication can be performed using XMLHttpRequests, HTTP, tcp/ip and perhaps others. Since there are various layers of API and scripting, we will call this the indirect networking approach. All the pros and cons are beyond the scope of this document but one relevant and important pro and one con will be mentioned. On the plus side, this method is easy and flexible for an experienced programmer to implement. It has historically been the most common approach used for Web3D (see also [1] and [2]). On the negative side, the various layers are subject to a variety of market driven changes beyond the control of X3D Consortium leading to high risk and maintenance costs (see [8, 9]).
3.2. Internal Script node networking
This approach makes use of a java or C++ class inside of the script node to communicate via the network. The ECMAScript of language of X3D does not support network I/O, such as tcp/ip, other than the usual http URL fetch. As such it is mid way between the fist option above and the direct networking approach. The main benefit is that this option is available to experienced programmers now and has no real restrictions. The main con is that the content is not portable: if a java class is used it will not work on X3d Browsers that do not support java, if a C++ class is used then C++ classes may not be supported on all X3D Browsers.
3.3. Direct networking: this proposal
As the direct networking approach is described in this document and the links provided, only one pro and con will be mentioned. On the plus side, this method uses a node interface to directly connect the X3D event system to the network: avoiding the risks/costs of the first method and the portability problems of the second. The main con is that it is not currently supported.
4. Goals
The main goal of the Web3D Consortium Networking Working Group is to
propose amendments to the X3D specification to strengthen the specification's open standards networking capability in such a way that it:
- is portable across platforms (including Web3D Browsers),
- is defined at the node level so it is easier for content developer and authoring tools to use with limited scripting, if any,
- provides support for communicating to non X3D applications,
- allows the routing of events over a network using the same routing mechanism used for internal routing,
- provides for high efficiency transfer of data or nodes,
- supports secure communication,
- allows for possible error correction option (e.g. For wireless connections),
- supports the main Web/internet standards: http, tcp/ip, udp and possibly https,
- allows for streaming of media and level of detail (LOD), and
- can be used with interaction sensors.
Another goal of the WG is to define a set of best practices for Browser implementers and another for content developers. These documents should provide guidance on things like efficiency and security.
5. Action Items & Deliverables
The component specification drafts and recommendations of this group will be presented to the X3D Specification group along with the Amendment 3 process. Proposed amendments have already been drafted and can be found at: [5].
In addition, the group will provide a set of application use-cases and design rationale documents, which motivate the work and establish the metrics for success. Current use case documents can be found at: [7].
A firm decision as to what initial node specification to put in the next amendment is required by May 2007.
6. Participants
The current participants (more to follow, let me know if I've missed anyone) are:
- Tony Parisi, Media Machines
- Alan Hudson, Yumetech
- Leonard Daly, Daly Realism
- Dick Puck, PhD. Intelligraphics
- Don Brutzman, PhD. Professor NPS
- Chris Thorne, Msc, Phd hopeful, The University of Western Australia. Also of Ping Interactive Broadband.
- ... others TBA
7. References
- http://www.ajax3d.org/ajax3dwhitepaper.html
- http://java.sys-con.com/read/167012.htm)
- X3D. (2003). "Extensible 3D (X3D). ISO/IEC FDIS 19775:200x." Retrieved May 2, 2005, from http://www.web3d.org/x3d/specifications/ISO-IEC-19775-IS-X3DAbstractSpecification
- http://planet-earth.org/x3d/networkSensorProposal.html
- http://planet-earth.org/x3d/networkSensor.html
- http://planet-earth.org/x3d/ExampleNetworkSensor.html
- http://planet-earth.org/x3d/UIUseCase.html
- http://planet-earth.org/sg05/EvolutionaryAccident.pdf
- http://www.coachwei.com/blog/_archives/2006/9/27/2367882.html
- Pesce, M., Kennard, P. and Parisi, A. 1994. Cyberspace, First International Conference on WWW, Geneva May 1994.
--------------------------------------------
*e-mail: dragonmagi AT gmail.com
Any Consortium Member can join a Working Group. We offer student, professional, academic and company level memberships.
Consortium members can simply go to the Consortium Member Login area of the website to sign-up to join this work group