[x3d-public] External prototypes

[Roy Walmsley]

In Coin3D I have two classes - a Proto and a ProtoInstance. They both get
used for PROTO and EXTERNPROTO cases, with different flags. So I am like
you.

When I parse an EXTERNPROTO I load immediately after reading the declared
fields. I guess that could be inefficient if an EXTERNPROTO was declared but
never instanced. Then I instantiate ProtoInstance copies as and when needed,
copying the Proto fields and connections.

Either way we do it we are still loading, and completing all initial IS and
ROUTE before completion of the parsing stage, aren't we? Or do you save IS
and ROUTE until parsing is complete and then implement them?

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

> On the other hand, the creation and setting up of the instance takes 
> place when the file is being read in.

Uh-oh. I did it differently in freewrl: I lazy-load the EPD, and bodify the
EPIs after that. freewrl used to load the EPD during scene parsing, but
there was an issue with that. I changed it so EPD, EPI, PD, PI, Inline all
share the same struct (with different flags). Now EPIs get the EPD interface
and empty body during parsing, and when the EPD definition shows up later, a
copy is instanced in the body of each EPI, and IS routing done between the
EPI interface and PI interface. So freewrl -with some changes- could in
theory send an event out the (inline) .load field after IS routing.


> 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/comp
> onents/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/comp
> onents/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
>
> x3d-public at web3d.org<mailto:x3d-public at web3d.org>
>
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
 		 	   		  
_______________________________________________
x3d-public mailing list
x3d-public at web3d.org
http://web3d.org/mailman/listinfo/x3d-public_web3d.org