[x3d-public] [x3dom-users] Whither protoexpander in X3DOM? umm, just define input-to-output and write code; refresh, security considerations
Don Brutzman
brutzman at nps.edu
Fri Jun 26 07:27:39 PDT 2020
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
More information about the x3d-public
mailing list