[x3d-public] ProtoBody completeness in nested Protos

[Andreas Plesch]

> Date: Tue, 26 Apr 2022 07:56:47 -0600
> From: GPU Group <gpugroup at gmail.com>
> To: X3D Graphics public mailing list <x3d-public at web3d.org>

> When I started with freewrl around 2009, it had a text-based system for
> protos:
> - when parsing a scene, if it found a proto declare, it would scrape the
> text into a buffer. Then as it continued parsing, when it hit a proto
> instance it pasted, and continued parsing over the pasted text as though it
> had been there all along. Extern protos similar, it would pause parsing, go
> to the file referenced, look for the proto declare by name, and scrape out
> the text of the ProtoDeclare, for pasting in-scene.
> And it worked a bit. But especially extern protos weren't working reliably.
> As a casual volunteer I decided to fix the bugs. How hard could it be? A
> little debugging and presto, I'd be a hero. As I got into it and saw more
> scene failure examples there were several emotional stages like grieving
> denial, shock, sadness, resistance etc. And a slow dawning realization the
> whole system needed a rework.
> And I didn't have support from others -just silence, perhaps they knew it
> was a mess and wanted to stay clear.
> It was a sickening feeling, and I needed to think for a few weeks whether I
> even wanted to be a volunteer programmer if the system was rotten from the
> core.
> So it can not only be a monster task, but precisely because it's a monster
> there's little support for those brave enough to tackle it.
> (After a few weeks I got to the Acceptance stage of grieving, and spent 6
> months of hobby time building the new proto system).

Thanks for the story, and for engaging. To me, I became interested
when I realized that x3dom is probably flexible enough to allow for
parameterized definition and registration of new nodes dynamically
which behave then exactly like native nodes. This is different from
filling in templates. For example, there is no performance penalty
during tree traversal and it enables instancing using xml nodes with
the new names, just as in x3dv.

I am pretty happy with how it came out. An additional complication is
asynchronous loading of remote resources which is standard on the web.
X3D should rely less on how nodes or statements are ordered in a
scene.

It is just frustrating that there are ill defined corners. I really do
not think that proto declarations should be required to inherit
existing declarations from parent execution contexts ( DEF/USE name
scopes are different but there is still a separated execution context
). That means the protos array of a new execution context should be
empty initially. The SAI spec. actually says so.

Best, Andreas