10/22/98 2:23 AM From: Don Brutzman Subject: Re: Call for WG's to submit requirements To: Murat Aktihanoglu CC: www-vrml@vrml.org, Jeff Close , DIS-Java-VRML Working Group , GeoVRML Working Group Murat Aktihanoglu wrote: > > Hi, > I'd like to invite all the WGs to submit their requirements for VRML NG to > the list. Thanks for asking. These circulated without argument (cough!) on the dis-java-vrml list. A few additions have been tossed in. Together these represent lessons learned during several years of cumulative, painful effort which included 6-8 contributors to a very large body of code. dis-java-vrml hit a number of major hurdles which the next-generation specification ought to be able to fix. the VRML-NG design needs to ensure that the needs of code library developers (uh, people like us :) are represented. Please add code library developers to browser builders, content developers, users etc. when identifying interested constituents for VRML-NG. Incidentally djv is delivering on one of our stated charter goals by submitting this list for discussion. p.s. i perused these djv files while thinking about these issues: http://www.stl.nps.navy.mil/dis-java-vrml/workList.html http://www.stl.nps.navy.mil/dis-java-vrml/ReleaseNotes.txt and our mail list archives ========================================================================= proposed VRML-NG requirements from dis-java-vrml working group: - require Java 1.2 (or better) support for network-profile VRML browser compliance. both multicast and unicast socket support required. - require a single consistent Java CLASSPATH configuration that works for all VRML browsers. CLASSPATH must not require any end-user intervention and is installed automatically with the browser. - require a single consistent set of calls to the Java security model for network socket access that works for all content in all browsers. again, both multicast and unicast socket support required. - require url support for .jar Java Archive files. This is essential so that a single class which is part of a package can be referenced across the network. Nonsupport for .jar is unacceptable because it means that packages can only referenced following user installation on a local hard disk. currently we are not allowed to think thoughts bigger than one class file across the network - this is unacceptable! - require consistent syntax and semantics, for script authoring & VRML node DEF naming, for authors working with any combination of Java/VRML/HTML. This needs to work whether using Java via the Script node (scripting inside VRML scene) or External Authoring Interface (EAI) (scripting outside VRML scene, in the external HTML web browser). - require conformance tests to ensure that Java-VRML script classes run across all possible combinations of operating systems/web browsers/VRML plugins. - require that VRML browsers report specific file name, line number and problem description when encountering errors or warnings in VRML content. - provide support for automatic bug reporting to scene authors from end users. - define VrmlDoc commenting convention similar to (& compatible with) JavaDoc so that VRML scenes and script classes can both be auto-documented by developers producing VRML content and script code. For example Javadoc, see http://www.stl.nps.navy.mil/dis-java-vrml/docs/index.html - define a java package naming convention for public vrml-java code libraries. (e.g. vrml.dis.* instead of mil.navy.nps.dis.*) and require global uniqueness adjudication by a naming authority and repository. - require a single consistent Java CLASSPATH configuration that works for these public vrml-java code libraries. CLASSPATH must not require any end-user intervention and is installed automatically with the browser. - consider extending these package naming conventions to script packages in other languages as appropriate. ensure IDL compatible. - require that Script interfaces include Interface Description Language (IDL) bindings definitions, so that CORBA & other programming-language-neutral approaches can be used. - adopt a globally unique naming convention that permits nonambiguous identification of entities, avatars, virtual vehicles, etc. - adopt the GeoVRML standard coordinate system conventions for georeferencing. - require Network Time Protocol (NTP) or GPS receiver support for computer clock (and hence timestamp) synchronization. - require support for real-time object-to-object collision detection in VRML-NG browsers. The V-Collide paper by Dinesh Manocha, Ming Lin et al. of UNC in the VRML 97 proceedings shows that this is computationally feasible (~625 high-polygon bunnies bouncing off walls and each other in real time). - F=ma physics does not need to be incorporated into the specification since models are highly variable and can be implemented via Scripts. However object-to-object collision detection must be easily accessible or any such calculations can easily become erroneous. - maximize backwards compatibility with VRML 97 - require an open-source VRML-NG sample implementation to support specification and application development efforts. all the best, Don -- Don Brutzman Naval Postgraduate School, Code UW/Br Root 200 work 831.656.2149 Monterey California 93943-5000 USA fax 831.656.3679 Virtual worlds/underwater robots/Internet http://www.stl.nps.navy.mil/~brutzman