<div dir="ltr"><a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/dis.html">http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/dis.html</a><br><div>Q1. should DIS be dropped from future specs</div><div>Q2. is there a more web3d-like way to do something like it?</div><div>-Doug</div><div><br></div><div><br></div><div>I can see why this isn't widely implemented.</div><div>x half-baked - looks like student papers - just a prototype or proof of concept</div><div>x only one implents it -xj3d-, and I have yet to see it run with DIS nodes (it whitescreens on me when run from x3d-edit), so difficult to reverse engineer fuzzy concepts</div><div>x the flavor of some nodes like radio transmitter, receiver, signal seems too specific/high level compared to the rest of web3d which is more about general capabilites that can be combined flexibly in many permutations</div><div>x the DIS specs are very 1990s like</div><div>x DIS specs are big</div><div><br></div><div>But it also seems to fill some gaps versus EAI:</div><div>* node level synchronization (versus EAI access via rootnode > tree)</div><div>**- so easier to bury inside proto bodies</div><div>* wireline protocol </div><div>** so compatible among any browsers or utilities that implement the protocol</div><div>* no server -peer-to-peer, nothing bad happens if peers join or leave</div><div><br></div><div>And it has problems:</div><div>- using broadcast udp means no ACK / resend if packet lost</div><div>- better at regular / heartbeat updates </div><div>-- if one is dropped, just wait a few seconds</div><div>-- if peer joins late, just wait a few seconds</div><div>x, poor at one-time state intializations / transfers </div><div>xx if packet lost, DIS spec full of bandaids for this issue</div><div>xx if peer joins late, awkward</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div>