<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Segoe UI Emoji";
panose-1:2 11 5 2 4 2 4 2 2 3;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style></head><body lang=EN-US link=blue vlink="#954F72"><div class=WordSection1><p class=MsoNormal>I think WebRTC would be okay, if not ORTC. Check which vendor supports what parts of the API though.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I have a similar lack in familiar with SIP, and would choose something simple, old, and familiar, such as IRC (look how easy it is to debug the network protocol!), but IRC is no where near real-time, nor enterprise-safe. I know that hierarchical or graph network protocols are a bear to debug unless you use text instead of numbers. But yeah, a network protocol that I can switch between text and binary would be okay (the way HTTP and HTTPS use gzip would be an example of that). We need a very fast compression algorithm I think though. Would EXI be fast enough?</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>But yeah, whatever the browser vendors support as a standard would be OK with me. But at what point do you get to</p><p class=MsoNormal>Browser = Ubuntu? Should we reserve something outside the web space for special case applications? Or can I render the POSIX API irrelevant these days?</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Still a happy bash and vim user. I do want my 2D/3D apps to run on mobile, so I can show my wife and daughter.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>John</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Sent from <a href="https://go.microsoft.com/fwlink/?LinkId=550986">Mail</a> for Windows 10</p><p class=MsoNormal><o:p> </o:p></p><div style='mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='border:none;padding:0in'><b>From: </b><a href="mailto:christoph.valentin@gmx.at">Christoph Valentin</a><br><b>Sent: </b>Monday, March 11, 2019 12:52 AM<br><b>To: </b><a href="mailto:yottzumm@gmail.com">John Carlson</a>; <a href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a><br><b>Subject: </b>Re: [x3d-public] x3d-public Digest, Vol 120, Issue 34</p></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Comparing SIP with XMPP.<br><br>Cannot technically compare both due to lack of know how about XMPP,<br><br>And what about WebRTC. <br><br>Many possibilities. Choose wisely:-)<br>-- <br>Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.<o:p></o:p></p><div><p class=MsoNormal>Am 11.03.19, 06:35, Christoph Valentin <christoph.valentin@gmx.at> schrieb:<o:p></o:p></p><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:4.8pt;margin-right:0in'><div><p class=MsoNormal style='margin-left:4.8pt'>Ĺooooong ago this was already suggested. I don't know much about XMPP. Maybe Sven-erik can answer.......<br>-- <br>Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:4.8pt'>Am 11.03.19, 06:30, John Carlson <yottzumm@gmail.com> schrieb:<o:p></o:p></p><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:4.8pt;margin-right:0in'><p class=MsoNormal style='margin-left:9.6pt'>Or if you want to work with a more “established” network protocol, XMPP:<o:p></o:p></p><p> </p><p class=MsoNormal style='margin-left:9.6pt'><a href="https://en.wikipedia.org/wiki/XMPP">https://en.wikipedia.org/wiki/XMPP</a><o:p></o:p></p><p> </p><p class=MsoNormal style='margin-left:9.6pt'>Good luck!<o:p></o:p></p><p> </p><p class=MsoNormal style='margin-left:9.6pt'>John<o:p></o:p></p><p> </p><p class=MsoNormal style='margin-left:9.6pt'>Sent from <a href="https://go.microsoft.com/fwlink/?LinkId=550986">Mail</a> for Windows 10<o:p></o:p></p><p> </p><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='margin-left:9.6pt'><b>From: </b><a href="mailto:yottzumm@gmail.com">John Carlson</a><br><b>Sent: </b>Monday, March 11, 2019 12:07 AM<br><b>To: </b><a href="mailto:christoph.valentin@gmx.at">Christoph Valentin</a>; <a href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a><br><b>Subject: </b>RE: [x3d-public] x3d-public Digest, Vol 120, Issue 34<o:p></o:p></p></div><p> </p><p class=MsoNormal style='margin-left:9.6pt'>May I suggest a CSV-like protocol across the https or TLS/SSL network, similar to:<o:p></o:p></p><p> </p><p class=MsoNormal style='margin-left:9.6pt'>(SSL-initiation)<o:p></o:p></p><p class=MsoNormal style='margin-left:9.6pt'>COMMAND1,TIME1,PARAMETER1,PARAMETER2,..\r\n<o:p></o:p></p><p class=MsoNormal style='margin-left:9.6pt'>COMMAND2,TIME2,PARAMETER3,PARAMETER4,…\r\n<o:p></o:p></p><p class=MsoNormal style='margin-left:9.6pt'>…<o:p></o:p></p><p> </p><p class=MsoNormal style='margin-left:9.6pt'>Will that satisfy the network nazis?<o:p></o:p></p><p> </p><p class=MsoNormal style='margin-left:9.6pt'>Also, we might use a STEP/EXPRESS-like format, if we want a hierarchical format.<o:p></o:p></p><p> </p><p class=MsoNormal style='margin-left:9.6pt'>Can we leverage X3DUOM-style XSD and our tools to create APIs?<o:p></o:p></p><p> </p><p class=MsoNormal style='margin-left:9.6pt'>What type of constrictions do we have to jump through to satisfy network ops? Should we make the protocol look just like an Excel file? <span style='font-family:"Segoe UI Emoji",sans-serif'>😊</span> <span style='font-family:"Segoe UI Emoji",sans-serif'>😊</span> Just wait until the first executive gets his excel file stopped by a network filter <span style='font-family:"Segoe UI Emoji",sans-serif'>😊</span>.<o:p></o:p></p><p> </p><p class=MsoNormal style='margin-left:9.6pt'>Maybe not, huh?<o:p></o:p></p><p> </p><p class=MsoNormal style='margin-left:9.6pt'>What types of interactions do we want to support?<o:p></o:p></p><p> </p><p class=MsoNormal style='margin-left:9.6pt'>John<o:p></o:p></p><p> </p><p> </p><p class=MsoNormal style='margin-left:9.6pt'>Sent from <a href="https://go.microsoft.com/fwlink/?LinkId=550986">Mail</a> for Windows 10<o:p></o:p></p><p> </p><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='margin-left:9.6pt'><b>From: </b><a href="mailto:christoph.valentin@gmx.at">Christoph Valentin</a><br><b>Sent: </b>Sunday, March 10, 2019 10:34 PM<br><b>To: </b><a href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a><br><b>Subject: </b>Re: [x3d-public] x3d-public Digest, Vol 120, Issue 34<o:p></o:p></p></div><p> </p><p class=MsoNormal style='mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:9.6pt'>>>>>>>It may be time to come up with some proof of concept implementations of nodes or infrastructure around a scene using web technology before more thought experiments.<br><br><br><br>>>>>>Andreas, <br><br>I don't mean to interject in your conversation, but my earlier comments (below) were not merely "thought experiments". Most of everything I've talked about is already implemented and working at <a href="http://officetowers.com">officetowers.com</a> (The server is currently suffering from a database malfunction, so login is not currently possible until next week, but I can assure you. Meanwhile, videos are available if you'd like to see them).<br><br>That world and its associated X3Daemon multiuser server, have been ready for a network sensor for years. But before potentially spending hundreds of hours in implementing one in a new version based on more modern practices and available technologies, I'd like to see what we can come up with as a consensus. <br><br>What is exactly a network sensor? What are its functions? Within what boundaries and parameters? Do we refer to the earlier draft (when work on it stopped) as a basis? IMO, those are some of the questions that need answers before we can contemplate creating specs for a NS. <br><br>Cheerz,<br>Gina-Lauren <br><br><br><br>[Christoph]<br><br>Hi Gina-Lauren, Hi Andreas,<br>It's me, who should not disturb fruitful discussion here, but waiting for Andreas' response I'd like to add my two cents. <br><br>Just assume the members could agree on a test setup and they could motivate enough manpower to "do it".<br><br>A) How could such test setup look like?<br><br>B) Assuming the test setup and the specs would be developed in parallel, what would we need from the specs?<br><br>As I said, just my 2c.<br><br>Have good luck :-)<br>Christoph<o:p></o:p></p><div><p class=MsoNormal style='margin-left:9.6pt'>Am 11.03.19, 03:38, GL <info@3dnetproductions.com> schrieb:<o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:4.8pt;margin-right:0in;margin-bottom:0in;margin-left:.2in;margin-bottom:.0001pt'><br>>It may be time to come up with some proof of concept implementations of nodes or infrastructure around a scene using web technology before more thought experiments.<br><br><br><br>Andreas, <br><br>I don't mean to interject in your conversation, but my earlier comments (below) were not merely "thought experiments". Most of everything I've talked about is already implemented and working at officetowers.com (The server is currently suffering from a database malfunction, so login is not currently possible until next week, but I can assure you. Meanwhile, videos are available if you'd like to see them).<br><br>That world and its associated X3Daemon multiuser server, have been ready for a network sensor for years. But before potentially spending hundreds of hours in implementing one in a new version based on more modern practices and available technologies, I'd like to see what we can come up with as a consensus. <br><br>What is exactly a network sensor? What are its functions? Within what boundaries and parameters? Do we refer to the earlier draft (when work on it stopped) as a basis? IMO, those are some of the questions that need answers before we can contemplate creating specs for a NS. <br><br>Cheerz,<br>Gina-Lauren <br><br><br>________________________________________________________<br>* * * Interactive Multimedia - Internet Management * * *<br>* * Virtual Reality -- Application Programming * *<br>* 3D Net Productions 3dnetproductions.com *<br><br><br><br><br><br>Hello Andreas, Christoph and all,<br><br><br>>I looked at the network sensor, and BS Collaborate nodes. I think the idea is to explicitly forward all events which need sharing to the server which then distributes those to connected clients. <br><br><br>I'd say it's a fair assessment, though there are also a little more, behind the scene events, such as avatar authentication, login/logout, standby/resume status, and other similar network connections that are not necessarily shared in the scene per say.<br><br><br><br>>This leaves the definition of the shared state to the scene, and therefore requires careful design and code for MU. Perhaps there is a way that the browser can better assist with making a scene MU capable.<br><br><br>X3D is very capable of doing this internally, but I'd definitely want it to have its own script node. It may be possible to pass simple events through the browser, but that solution would impose severe limits to the ability to perform multiuser tasks in general. I mean, it can get convoluted enough as it is, without adding the extra complexity of passing events and network connections back and forth through the browser. I understand it isn't easy, but if it can be done, we probably should do it.<br><br><br><br><br>>What is the complete state a client needs when it is admitted to a shared scene ?<br><br><br>From my experience, that will depend very much on the use case, but generally, the scene is complete within each client, though avatars and/or objects may be hidden and not necessarily seen at any given time. When the client connects to the shared network, that's pretty much when state is established. There may be exceptions to that, for example when an avatar has a specific identity and/or status in a game or accumulated points, that information will typically first be obtained from the server's database, before being passed on to the client and in turn to the network. <br><br><br><br>>Since most fields of most nodes accept input, and can therefore potentially change, complete state probably means just the value of all fields of all root nodes which means all nodes. The complete state may only need to be transferred when a client joins.<br><br><br>Ditto. Yes exactly. See above.<br><br><br><br>>Plus the offsets of avatars from Viewpoints. And the clock. Perhaps other values.<br><br><br>Again yes, so avatars don't end up on top of each other for example. <br><br>As far as a clock, I have never shared one or felt I needed to thus far. In my implementation, each client simply polls the server at regular intervals of one, two or more seconds (depending what other subsystems are in place). We sometimes cannot allow a client which is experiencing latency for one reason or another, to hold back all of the other clients. The show must go on, whether a client gets disconnected or happens to get out of sync. It generally seems to have little impact, since, at least in some cases, users are not together in one room. So they are in essence unaware that they are out of sync, as the case may be. <br><br>But, I can see how specific applications may need and would want to have a clock. And in that case, I believe we should take a good look at what the MIDI standard has to offer. MIDI is a well established and solid standard that has many uses for timing and control, not just music, and is more than likely a very good fit for virtual reality.<br><br><br><br>>I was thinking about avatar initiated event cascades since the state of everything else should be deterministic and only depend on time. These other things should update themselves. There are exceptions such as scripts which generate random values.<br><br><br>Avatars with gestures, and also all kind of visible objects, such as doors, cars, elevators (that's a tough one), a cup of coffee, a guitar, clouds, stars and anything else that moves. But also various more subtle things like say group chat, or items inside pockets or bags, money, ammunition and things of that nature also need shared states, and sometimes to various levels of privacy. <br><br><br><br>>Avatar initiated event cascades generally start with environment sensors. Not sure if there are other ways. The idea would be to just have to transmit this event cascade to other clients which then can replay it to update their scene instances. <br><br><br>Sure. General user interactions with the world and its interface, such as buttons and inworld devices, often need to be shared as well.<br><br><br>>I also was reading some of the github open-dis documentation. Interesting background, and pretty accurate discussion on coordinate systems. It may be possible to set up somewhere a very simple distributed simulation to join and test clients with.<br><br><br>I remember the DIS-Java-VRML work. That was very good. I will take a closer look at Open DIS as you mentioned. It sounds interesting. As I began to touch above, each MU implementation will have their own particularities. Personally, I would very much like to see a general NetworkSensor node that would be flexible enough to accommodate different protocols, but also one that has the ability to be adapted to specific use case and needs. <br><br><br><br>>Single browser MU: I think an additional touchedByUser field would be required but perhaps there is a way to generalize tracking of Users.<br><br><br><br>I don't know if it's possible, but I'd like to see the possibility to add any number of fields to the network node. Fields that would be defined by each implementation as needed, as we may not be able to always predict its application.<br><br><br>I feel there is much more to discuss, and I'd re-iterate my suggestion to open a NetworkSensor group or similar, so as to allow for more detailed exchanges and begin to have some basis for VR networking.<br><br>Gina-Lauren <br><br><br>P.S. Your work with Python is very interesting and falls in line with some of my own thoughts. <br><br>________________________________________________________<br>* * * Interactive Multimedia - Internet Management * * *<br>* * Virtual Reality -- Application Programming * *<br>* 3D Net Productions 3dnetproductions.com *<br><br><br><br><br><br><br><br><br>_______________________________________________<br>x3d-public mailing list<br>x3d-public@web3d.org<br><a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><o:p></o:p></p><p> </p><p> </p></blockquote></div></blockquote></div><p class=MsoNormal style='margin-left:4.8pt'>_______________________________________________ x3d-public mailing list x3d-public@web3d.org http://web3d.org/mailman/listinfo/x3d-public_web3d.org <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>