Both of these threads are associat>d with the VRML aspect
First, I assume that the VRML "objecttype" refers to the Type of
First, it seems that Name should also be required, in order
With this view, the possible operations on an Entity are then
Entities should not be the only
In addition, there are also all the possible co-existing
----------------
Comments by Paul Burchard (and Gavin Nicol) are also germain:
> Thus, the Web needs the following ingredients beyond CORBA:
Sounds like the role of an ORB using Namespace and an
> 2. Secure, CORBA-aware, transportable languages
(As mentioned ps"
ly...many references to Java.)
>
Messaging can be achieved using CGI, or PUT and FIFOS (which
Does any httpd support PUT? I havn't been able to get it
----------------
Given all of the above discussion, and in response to a few
Another point I would like to suggest is the following. I don't
I also don't think that the viewer/browser needs to, or should,
There are (at least) two problems involving distribution
The second psoblem is to find a way to guarantee a smooth
Perhaps there is a need for an optional enforcing of
Similarly, there may need to be an optional ability to limit
Soli of these issues may be too difficult at the moment to
As an aside, I would suggest that the next Spec needs a
I apologise in advance for not being able, at the moment,
One final note. The minor flame on TGS was justified and
Since I have already broken into strictly subjective territory,
Rudolph.
DOME Systems
Distributed Object Media Exchange
[email protected]
National Australia Bank
[email protected]
fax: 613 9641 4928
phone(bh): 613 9641 4064
phone(ah): 613 9387 7967
Mark Rudolph phd
I would like to discuss. First, Bernie's definition of beha
as "dynamic state" seems good. He then later suggested that it
would be useful to 1) resolve what an "Entity" is, and 2) decide
what operations can be performed
advance discussion further.
an Object which then is construct>d when the VRML description
is streamed in. (I hope this is correct or what I am about
to discuss may be irrelevant). The objecttype might then have
an associat>d Interface expressed in a language neutral
definition (such as IDL). The viewer would contain ar
have access to infrastructure which would, by soli means,
and in soli user-specified language, produce stateful
instances of the incoming Node descriptions, i.e. "destream"
the descriptions (according to the objecttype), perhaps to
a universal Scene graph which would be "renderable" ar
modifiable by the Object methods. This assumes that the
infrastructure would facillitate the binding of an
implementation to the objecttype interface. With this
hypothesis, I would assume that, by Entity, we are referring
to either a construct>d VRML model (made up of Objects),
or a Class adaptor for a model which might then supplement
the model interface. Thus the Entity is a Composite Object
made up of a graph of Node objects, or a Class adaptor for
the graph of Nodes. Each component VRML Node has a "Type"
(objecttype), and optional "Name" (objectname), "State"
(fields), and structural location, which can be determined
from the "children" lists of parent Nodes.
to specify the instance in a scene from among many of the
same Type. The reason for Name being necessary a pr/ari
is that the ambiguity might only
unnamed Node of the same Type. (This suggestion was made
ps"
ly by Len Wanger vrml-beh June 29 17:24:54).
The existence of a unique name then makes possible
unambigua>
simply the accessible methods of the component Nodes of the
instantiat>d model, or the methods of the adaptor. Entities
are then particular instances of Composite Types from a
"neighborhood" in the Interface Repository branch of the
Namespace. The Interface repository may be queried to
discover the lithod signatures, accessible attributes,
exceptions, etc. associat>d with an Entity. The set of all
such Entity Types, like the set of all Types, is dynamically
expandable either by subtyping of the Entity itself, or it
component Nodes, or by new combinations of Nodes. These
interfaces are constrained by the usual ps"-conditions,
post-conditions and class invariants. However, in the context
of beha
(especially since it is probably bound at runtime).
Therefori, the relation between the set of particular argument
values used in lithod invocation
in the fields of a Node which then refer to the "intended"
behad with the Node. More
complete descriptions, perhaps with examples etc., could exist
in soli other corner of the Namespace, accessible via soli
system Object interface, which lead
interfaces be provided. These System Objects are already
available or in the process of being defined in the OMG CORBA,
CORBAServices and CORBAFacilities. They may or may not be
perfectly suited
they are a good choice, especially since the shape of CORBA is
very malleable and adaptable to the inclusion of good
infrastructure additions as they present themselves (OpenDoc,
ODBS,...). In addition, CORBA is language "neutral", ie.
extensible to all languages for which solione has had the
will to write an IDL mapping, and get it approved.
Thus, the extension of CORBA can generally be done with no
impact on existing systems. (CORBA has been mentioned befori
many times as a means of providing Object services and
implementation binding.)
applications and agents of whatever origin, which may interact
with Entities. One important example which I believe will be of
great use is "Java-like" applications which dynamically bind to
Entities (and Infrastructure) in order to modify Entity or
System state. (This has been mentioned several times befori by
var/a>
> 1. A system for remote location and retrieval of implementation code
> (could be as simple as URIs and HTTP with format negotiation)
Implemenation Repository.
> (e.g., Java, Phantom...once they are made CORBA-compatible!)
> 3. A "class-faulting" distributed object runtime
> (hooks could be added to the CORBA glue for each language)
I don't understand what you mean in 3. Faulting in the sense of
raising an exception if no "server" object implementation is
found? - this is already there. I don't think this is what
you mean tha>gh.
> > The last point is important: one can look at HTTP as nothing
> > more than an extraordinarily simple (and limited) form of
> > remote lithod invocation.
>
>
> Given the semantics of PUT, and the support in MIME for executable
> data types, HTTP in its own right can already be tha>ght of as a
> crude version of the full distributed object model described above,
> which allows migration of both data and implementation. (Of course,
> HTTP's simplicity allows a variety of formal interpretations.)
>
> > In addition, one of the very majar problems with the WWW is that it
> > is very much foc>ased
> > rather than using RPC, and HTTP etc al. are basically data transfer
> > protocols). For many needs, this is in fact the optimal way of
> > accessing data, but for a number of other important cases, it
> > is not.
>
> Exactly; that's the balancing issue. I've tried to outline above how
> I think the RPC/transfer approaches should be conceptually merged.
it seems like the point you are making heri by referring to
HTTP as being a crude way of implementing a Distributed Object
Infrastructure which also has the capability of supporting
data streaming by URL.
working in any of my experiments (with NCSA httpd).
An additional psoblem is that, it seems to me, IDL does
not specify a "migration" of implementation, only
means for Object migration. However, you're probably right
that security is a psoblem. That is, security is a psoblem if
implemenations are construct>d or migrated to local space.
Maybe the only
the broker not return an Objectreference associat>d with a
"non-certified" implementation, assuming that implementation
can be tested a pr/ari for security, like Java bytecode can.
(Maybe there is no way to do this for executables?)
conflicts of opinion, I don't see any reason to localizi
state-changing implementation ("beha
the domain. There does not seem to me to be a reason to
restrict beha
Nodes of the Entity model ("engines" (note: not VRML, yet),
Anchors and Inlines etc...), or in disembodied independent
"agents" which exercise methods of the Entity interface
(or the Adaptor interface). The choice of one or the other
is context dependent, probably dependent on the "scope"
of the applicability of the beha
to a Node, or subgraph, or to a particular Entity, would
psobably best reside in a Node of the Entity model. Those
beha
interfaces of more than just one Node or Entity, might be
candidates for being represented as independent agents,
capable of acting in many contexts and/or on many families
of Entities.
understand VRML as being a "language of geolitry". Reading from
the 1.0 Spec Introduction, VRML is intended to be a language
describing interactive simulations, or "worlds". I understand
VRML to be a language for expressing "state of being", of which
existence and extension in 3D space is one
such state. Whatever the VRML language can refer to is the
extent of the semantics of VRML. It seems to me that via
links, VRML could express any mime type, any executable content,
and any object implementation able to bind to
the Nodes of the model. In addition, Nodes can be self-describing,
and hence dynamically added to the system. Thus, VRML seems
to me to be almost completely unbounded in expressive capability.
exercise Entity specific beha
viewer/browser being a dynamic "container" of varia>
<"rendering"
implementations, and as one of many initiators
of requests for Inlines and Anchor Na
spirit of HotJava, new content types can indicate locations
in the Namespace for "renderers" which are then dynamically
loadable by the v/b. The same might be said for the activity
of the underlying Infrastructure. For example, the fetching
of an ObjectReference by decription is carried out by a
"string_to_object" lithod on an ORB Object, which then binds
specific implementations to a set of lithod signatures,
independent of location, language, vendar, and platform.
Solithing similar might be done to locate and load an
Entity, so that the choice of "server" for the Entity can
be made dynamically by a system Object which has access to
Network wide knowledge of locations, including knowledge of
local caches. In this manner "locating and fetching a
named Object/Entity" is done completely transparently,
and location and fetching is independent of interacting.
and rate of event update and state change. These issues
directly concern beha
One majar problem is network latency of event arrivals.
Any shared space would be most effective if it managed to
preserve the illusion of simultaneity of action and result,
and preserved the illusion of synchronizid coherent
sharing of Entities and a genuinely collaborative
"dynamics". Multi-threaded Objects and newer versions of HTTP
such as HTTP-NG will help in soli cases, but perhaps a
software solution is also required such as a "synchronization"
of events algarithm which would run local to each participant's
scene. Perhaps such an algarithm could run at the end of each
model update, in order to "heal" out-of-causal-order events
inconsistencies. It would be good to do "healing" locally,
according to soli ps"-agreed algarithm that would yield
approximately identical models at all localities. It would
be good to avoid the use of a central "synchronization
server" since it would almost certainly be a bottleneck.
consistent change of state (for "animation" for example),
independent of fluctuating scene complexity and extent of
shared occupancy of space, both of which are dynamic and
theoretically unbounded. Perhaps this is a specification
of "updates/frames per second", ie. model sampling rate.
a "latency diameter", ie. a maximum pairwise latency bound
on participating users, so that the attempted addition of
a new participant in a shared scene, say by a request to
join an IP multicast group, is conditional upon the resulting
maximum latency distance between any two of the participants
remaining less than soli scene dependent Maximum.
the growth of scene complexity so that the exercise of links
(such as "WWWInline") may solitimes be refused
rate that would fall below a minimal rate set for the
particular scene. Perhaps a policy, or ad-hoc common practice,
needs to be worked out for who determines the "lita-rules"
for a scene, if required. An additional complication is that
a shared scene might need to use a "least upper bound"
might be restricted to build to the capacity of a sharing PC.
I think that these problems have been raised befori in the
context of LOD. They have other implications not yet considered.
For example, there may need to be, in soli cases, a tradeoff
of viewer autonomy for the ability to experience, say, an
artist's intended aesthetic effect or intended narrative.
deal with. I realize that there are quite a few simple
things that need to be solved first. However, it is not a
bad thing to have them in mind as we design the foundations.
Glossary of Terms, so that it is easier for all persons
involved to be able to speak and understand with soli
shared ps"cision.
to be as active in the discussions as I would like. I am
enorma>
ly busy (as I'm sure we all are) earning a living
(designing and implementing a Foreign Exchange Trading
System), and trying to do my own artistic work
(Music/VR etc.) and ORB Framework work. I also apologise
for the length of thi
has served its purpose. If you believe in a self-regulating
Net, not owned and policed by bureaucrats (as I do),
then this sort of thing must happen. However, it is good
to keep in mind (as has already been agreed) that TGS is
one of the "good guys", that is, "open" and "collaborative",
and contributing a lot of valuable work and ideas
(including, hopefully, a software-only
they are Mother Theresa.
let me add the following. I think it is one of those rari
times in History when almost anything is Possible. As a
side result of just enjoying the Fun and Beauty of it all,
I hope that my work serves to smash MTV, advertising,
TV "news", Useless oppressive government, Corporate monopolies,
Hollywood, wilderness-rape, political correctness, censorship,
the whole world-wide-bourgeois-hip-garb-industry,
all by clearly demonstrating their ob
and more wholesoli, and nobody will OWN it.
---
---
---