[x3d-public] [x3dom-users] Whither protoexpander in X3DOM? umm, just define input-to-output and write code; refresh, security considerations

[Don Brutzman]

ProtoDeclare modifications can be considered an authoring activity.

Once a ProtoInstance is loaded, it is loaded and running.  No provision is defined or expected that a ProtoInstance might update itself unilaterally.

If an author wants to refresh or update a ProtoInstance during run-time operations, then they should remove it and re-instantiate it.

Thus deliberate operations are maintained throughout.  Curiously if we allowed ProtoInstance to update itself automatically, that would be a security vulnerability.

A new field '[in out] SFTime refresh 0' is defined for Inline and ImageTexture and related multimedia-content nodes but has not been proposed for all X3DUrlObject nodes or ExternProtoDeclare.

* Mantis 1262: new field /refresh/ for Inline, ImageTexture etc.
   https://www.web3d.org/member-only/mantis/view.php?id=1262

==================================
I just added spec comment to that:
Full list of node candidates include Inline, ImageTexture, AudioClip, ImageCubeMapTexture, ImageTexture3D, MovieTexture, PackagedShader, ShaderPart, ShaderProgram.

TODO check forthcoming Sound component modifications for possible additions.

Script is a possibility but would need a close look at initialization semantics.

This has sufficient impact that we might consider X3DRefreshObject interface which implements X3DUrlObject.
==================================

We should look at all occasions where url is utilized to consider whether additional security warnings are appropriate in the X3D4 Specification.  This is in our X3D4 design goals but I did not find it in Mantis.  Added:

* Mantis 1313: Review and note security precautions for each component
   https://www.web3d.org/member-only/mantis/view.php?id=1313

"Need to review and note security precautions for each component.  This is similar to requirement for IETF RFCs."

On 6/25/2020 7:38 PM, Andreas Plesch wrote:
> I think that could be helpful. I do plan on merging the proto support
> into the dev x3dom version. But it needs to be pretty robust. For
> example, people will experiment with dom manipulation of protoinstance
> field values or even protobody nodes, and expect something to happen,
> like changing all instances by changing the proto definition, after
> the fact. Also adding a new protodeclaration to an existing scene
> needs testing but should work. Removing one is less critical.
> 
> Thanks, -Andreas

all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman