[x3d-public] External prototypes

Roy Walmsley roy.walmsley at ntlworld.com
Thu Mar 12 08:50:13 PDT 2015


That's an Interesting set of points you raise.

 

I agree that the LoadSensor probably can't be used  because the watchList
field requires nodes derived from URL object. And EXTERNPROTO, although it
has a URL, isn't a node.

On the other hand, the creation and setting up of the instance takes place
when the file is being read in. This will include things like IS and ROUTE,
etc. So as the loading takes place during the file loading phase there is no
need for the LoadSensor. Indeed, it wouldn't be able to send any messages
until the setup  phase was completed.  Thus, referring to Kristian's
comment, the loading phase for the file would proceed through the
EXTERNPROTO declaration until it came to the prototype instance. This would
then load immediately and be set up before reading the file proceeded to the
next node. Consequently ROUTEs could be used immediately after the instance
in the file. Obviously and dynamic routing (e.g. via Scripts) would not
start until the whole scene graph loading was completed and became live. So
there isn't an issue there.

 

Inline, on the other hand, does not have to read the URL during the setup
phase. The stated purpose of the load field is effectively one of input, not
output (although it is inputOutput type). So setting load to FALSE prevents
the Inline from loading until it is needed, as opposed to loading
immediately if load is TRUE. The specification makes no mention of any
output activity. So it would be necessary to use a LoadSensor if it was
desired to monitor an Inline.

 

I too have noted that you have to specify the list of fields For external
prototypes in two places. However, avoiding that can't be easily avoided.
The use of a subset of the fields does allow an author to only declare those
fields of the EXTERNALPROTOTYPE that need to be in the top level file.
However, there is no reason why all the fields should not be included,
albeit that the specification says "shall be a subset". I think the
specification ought to say "shall be all or a subset". Another suggestion
for V3.4 I think.

 

Roy

 

-----Original Message-----
From: x3d-public [mailto:x3d-public-bounces at web3d.org] On Behalf Of doug
sanden
Sent: 12 March 2015 14:15
To: X3D Graphics public mailing list
Subject: Re: [x3d-public] External prototypes

 

 

I suspect Networking component> LoadSensor
<http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/component
s/networking.html#LoadSensor>
http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components
/networking.html#LoadSensor

cannot be used, because the URL is on the EP declaration, not the instance,
and the declaration isn't in the scenegraph where LoadSensor can get to it.
And there are extra steps after the declaration is loaded, to populate the
instances and hook up the IS routes to the instance interface.

 

Networking Component> Inline has a .load field [in,out] and I suspect it
sends an event out TRUE when it's loaded.

 
<http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/component
s/networking.html#Anchor>
http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components
/networking.html#Anchor

Ideally EPIs would have that too.

 

> 

> Ideally I think there should be a .loaded event or testable field on the
externProtoInstance (the interface), so you can test / know when it's ready
for routing.

> -Doug

> 

>> when declaring external prototypes, the author needs to declare the 

>> subset of the interface she intends to use by replicating those 

>> fields from the prototype declaration (cf X3D spec 4.4.5.2)

>> 

>> What is the rationale behind this? Seem to make the implementation a 

>> little bit simpler, but since events that occure before the prototype 

>> has been resolved are ignored anyway, this is really just a little bit.

>> However it complicates the use of external prototypes because it's a 

>> popular source of error (at least for my first steps with prototypes 

>> at times when maybe the error messages in then popular X3D browsers 

>> where improvable).

>> 

>> But maybe I miss something.

>> 

>> Best,

>> Kristian

> 

 

 


_______________________________________________

x3d-public mailing list

 <mailto:x3d-public at web3d.org> x3d-public at web3d.org

 <http://web3d.org/mailman/listinfo/x3d-public_web3d.org>
http://web3d.org/mailman/listinfo/x3d-public_web3d.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20150312/3abc4857/attachment.html>


More information about the x3d-public mailing list