1)
I agree that employing 'Java' as our scripting language
makes the implementation of constraints or paths harder.
We must define a very elaborate method interface scheme.
Also, General analysis should be performed on each scripting code
block, and the result should be kept all the time.
In VRML, Java compensates for the inherent weakness of VRML.
Then, I think, the capability of constraints or paths
could remove much of the work that Java should do currently.
For example, attaching a simple JavaScript code into the
script code would give with less efforts the same effect
that Java would achieve for VRML 2.0.
In summary, if we adopt constraints, then, we will be able to
make scripting language code much simpler, while it gives
the same effect as Java + VRML 2.0 architecture
with much more enhanced performance.
My argument is not expressing opposition to Java, but that
we can achieve good implementation of constraints if we
define the scripting language interface well.
> Note, that dependency lists have to be maintained in Java,
> they will not be part of the browser itself.
> I figured out how to translate paths
>
> <path> ::= SELF.<simplepath>
> | SUPER.<simplepath>
> <simplepath> ::= <fieldname> | <eventname>
> | <fieldname>.<simplepath>
> | <eventname>.<simplepath>
>
> in ROUTEs and as values of fields. Note, that
> the PARENT keyword is omitted because it seems
> difficult because of multiple parents and
> in many cases there is a work around by
> explicitly naming the parent using DEF.
2)
Then, we should name a node explicitly when the node is
accessed by its child node ? Since the scene graph is
tree-structured, PARENT seems to cause no problem.
(I am not sure ...)
>
> But when we add constraints (i.e. formulas,
> functions as parts of paths) and allow
> broken links and ...
> I am not sure this can be implemented
> efficiently. First we would have as the
> value of **every** field a special datastructure
> containing its value and a list of
> constraints for this field and a list
> of constraints depending on this field.
>
> Another point is, that I don't want to trade
> CLASSES and a static type system for constraints.
>
> I aggree, that we should add Amulet's 4 ways of inheritance:
> INHERITED, COPY, SHARED and LOCAL
> I expect, that these can be easily implemented.
>
> BTW do we aggree on these point:
> 1) Our extensions should be implementable with
> the VRML 2.0 and Java-Scripting
> 2) An author should be allowed to use VRML 2.0
> syntax in class definitions, this also implies
> that he is allowed to use ROUTEs
> The author should be allowed to mix VRML 2.0
> prototypes and our classes.
>
> The 2nd point is important. Our extensions should provide
> better means to express what ROUTEs can be used for,
> but we shouldn't remove ROUTEs. In other words we
> are talking about "extensions" not "changes" of VRML 2.0
> This important for our extensions to be accepted by
> a wide audience and to allow authors to gradually
> change their style of writing virtual worlds.
3)
This is directly related to the purpose of our working
group. I suggest that we make two proposals. One (extension) is
extending VRML 2.0, supporting every(or nearly every) element
of current VRML 2.0 syntax. Still, this proposal whould
improve VRML 2.0. The other (change) is adding other new concepts
to VRML, may have a significant change, may not support VRML 2.0.
I think this is a good compromise for our problems.
What do you think of this suggestion ?
-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Sungwoo Park, (Castle-Help Naive) homepage : http://compiler.kaist.ac.kr/~gladius e-mail : gladius@compiler.kaist.ac.kr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -