[x3d-public] External prototypes

[doug sanden]

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