>
>Ah, I've discovered my misunderstanding. You are proposing a change
>_in the meaning of WWWInline_, not just in the parser. I am afraid I
>was under the assumption that you were working with the 1.0
>specification of WWWInline. If you relax that assumption, then it
>becomes clear that one can parse this.
>
I definitely wasn't proposing a change. In what way was I coming off that
way? I'm now thinking it is prolly more accurate to say that I have a
misunderstanding about the VRML 1.0 definition of WWWInline. Lets start with
my under (or misunder) -standing. Here is what I was basing my definition on:
"The WWWInline node reads its children from anywhere in the World
Wide Web. Exactly when its children are read is not defined; reading the
children may be delayed until the WWWInline is actually displayed. A
WWWInline with an empty name does nothing. The name is an arbitrary URL."
This is from the spec. It goes on to talk about bboxSize and bboxCenter, but
that is about it. Now, you may have a more intimate understanding of it and,
possibly, it was left too vague in the spec. So, if we are to continue,
maybe you should fill me in on what was left out in the above excerpt and
how I have misunderstood or twisted it.
>One might do an incredibly expensive round of loading every single
>WWWInline before finding the one you need, and one might load the
>wrong DEF Foo first (if there are multiple of them), but it would
>work, just as well as it works in any linker.
Well, you shouldn't have a name collision, but yes, if the rules are
unclear, it is a possibility. But this is a much more refreshing discussion
than whether it is possible or not. The inability to do this efficiently may
make the feature undesireable. However, I think the effeciency has more to
do with the design of the page rather than the nature of the feature. Since
the author is the one inserting the links, its kind of up to him/her not to
do it in a way that is horribly inefficient. This is much the same as the
decisions an author will make in any aspect of VRML that can affect
performance. There's already been a lot of talk about how to author effeciently.
>
>Now we can agree to disagree over whether this is a _good_ idea. I
>was working under the assumption that you were changing only the
>USE/DEF semantics, not the semantics of WWWInline.
>
I still don't understand this. How do you feel that I was changing the
meaning of WWWInline? This issue is pretty important to me because I don't
want to be working under a false assumption.
>
>Let me simply state that I believe that the current WWWInlines make a
>great deal of sense for optimizing the responsiveness and net download
>time of very large scenes, and that any extension to allow a much less
>(IMO) desirable feature (inter-file variable scoping) goes against my
>better judgement.
>
Once again, I think this is up to the author. If he wants to keep all of his
basic shapes in a separate (.wrl), he can. However, I don't think this would
be a good idea and certainly not the most effecient way to present a VRML
Scene Graph. But those with a direct, T1 or ISDN line might like to do this
for group development of VRML projects that will not be publically available
until completed. When they are completed, they may turn their efforts
towards optimization.
>
>Yes, certainly, but I don't see any way to predict where to find a DEF
>without simply (down)loading everything.
>
Well, yes. But you don't have to download everything, once the global
symbols are resolved, you stop. What we are looking at, though, is a worst
case example resulting from the redefinition of the DEF/USE semantic. I
can't imagine people will author pages in this way. i.e. Just because
someone can author a horribly inefficient page, does not mean we should
prune VRML of every feature that if used in the wrong place or used with an
eye towards speed will result in slowness. If that were the case, there
wouldn't be much left of VRML.
>I certainly don't see why we wouldn't "load" (by which I mean parse)
>everything we download, though, so I don't understand how the
>underlined, above, would happen.
I'm not sure if I understand what you mean here. Do you mean, given my
statements, we would have to download everything? If so, I think I've
addressed this.
>
>Almost anything is possible given sufficient resources, but I don't
>agree we should make this particular tradeoff.
>
Understood. Realize though, that this is not the result of changing the
semantic of DEF and USE or the introduction of object naming and lexical
scoping. What we have been discussing is the worse thing that someone could
do with that new semantic and its resulting effect on performance. If this
is the worst case, I don't think it's too bad at all. If there are no
unresolved global names in the Scene Graph, this will never even come up.
Also, a smart server could even make this "worst case", not so bad by doing
lookups at the server component and serving up just the object being
requested and not the whole (.wrl).
Robert