[x3d-public] X3D and VRML for multiuser worlds

Sun Jan 10 20:11:01 PST 2021

My friends have asked me to set up a VPN on my machine in the past.  I
don't really see the value of a VPN.

On Sun, Jan 10, 2021 at 7:03 PM Christoph Valentin <
christoph.valentin at gmx.at> wrote:

> What I am going to try is to setup a VPN with OpenVPN and my vServer at
> hoststar.at, so we can do a test session with DIS (hopefully).
>
>
> *Gesendet:* Sonntag, 10. Januar 2021 um 23:13 Uhr
> *Von:* "John Carlson" <yottzumm at gmail.com>
> *An:* "Christoph Valentin" <christoph.valentin at gmx.at>
> *Cc:* "X3D Graphics public mailing list" <x3d-public at web3d.org>
> *Betreff:* Re: [x3d-public] X3D and VRML for multiuser worlds
> What I was going to do is try to get DIS from GitHub and DIS from X_ITE to
> talk to each other.
>
> John
> On Sun, Jan 10, 2021 at 1:08 PM Christoph Valentin <
> christoph.valentin at gmx.at> wrote:
>
>> ok
>>
>> let me repeat your proposal:
>>
>> >>>>> Of the published work available in that regard, we have BS
>> Collaborate, DIS, and the Draft X3D Specification for NetworkSensor. I
>> think the first step would be to take these, see what they have in common,
>> and go from there for deeper analyses.
>>
>> I think everybody agrees.
>>
>> So what would be the very first step (before the first step)? Assign
>> responsibilities? Create a Wiki? Ask for official decision? Just do it?
>> Who? What? When? Create an official backlog? Use the S&P-ARK?
>>
>> kind regards
>> Christoph
>>
>> --
>> Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail
>> gesendet.
>> Am 09.01.21, 07:40 schrieb Christoph Valentin <christoph.valentin at gmx.at
>> >:
>>
>>> Not much,
>>>
>>> 1) It's another use case, which has proven it's usefulness during
>>> SrrTrains v0.01:
>>>      - Customized Client Side Calculations
>>>          ( sent to x3d-public in January 2014:
>>> https://areasharpa.files.wordpress.com/2018/04/smuos_03_sema_2018_04_27.pdf
>>> )
>>>
>>> 2) And an idea (which is not yet settled).
>>>      - idea is to have two levels of identification:
>>>         identify the sensor by "streamName" + "networkSensorId"
>>>               (BS Collaborate: only "streamName"
>>>                 Octaga: only "networkSensorId")
>>>
>>>                 1) the stream = the model = the real life entity
>>> e.g. "car"
>>>                 2) the sensor nodes themselves
>>>                               e.g. "steering", "motor", "doors"
>>>
>>>
>>> *Gesendet:* Samstag, 09. Januar 2021 um 03:59 Uhr
>>> *Von:* "GL" <info at 3dnetproductions.com>
>>> *An:* "'X3D Graphics public mailing list'" <x3d-public at web3d.org>
>>> *Betreff:* Re: [x3d-public] X3D and VRML for multiuser worlds
>>>
>>> I am not sure what results you are referring to. Did I miss something?
>>>
>>>
>>>
>>> *From:* x3d-public [mailto:x3d-public-bounces at web3d.org] *On Behalf Of *Christoph
>>> Valentin
>>> *Sent:* Friday, January 8, 2021 9:21 PM
>>> *To:* 'X3D Graphics public mailing list'
>>> *Subject:* Re: [x3d-public] Re: X3D and VRML for multiuser worlds
>>>
>>>
>>>
>>> so basically you want to ignore my results?
>>>
>>> --
>>> Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail
>>> gesendet.
>>>
>>> Am 09.01.21, 01:07 schrieb GL <info at 3dnetproductions.com>:
>>>
>>> Christoph,
>>>
>>> Thank you for the clarifications and your general dedication. I believe
>>> that little misunderstandings should be addressed before they snowball into
>>> bigger misconceptions.
>>>
>>>
>>>
>>> > If we specify a general Network Sensor API, then content can run
>>> > with any X3D Player that supports the Network Sensor API.
>>>
>>> If you read again my last paragraph, I try to make a distinction between
>>> a multiuser client and a X3D player. In other words, the player is not
>>> necessarily the client. It appears to be a common misconception that the
>>> X3D player must also be the MU client, while in truth it really doesn't
>>> have to. For the reasons previously stated, I tend to prefer that the
>>> player does not in fact act as the client.
>>>
>>>
>>> > However, if I use the X3Daemon Client API, then I MUST use the X3Daemon
>>> > Server, because the protocol is proprietary.
>>>
>>>
>>> That is precisely why I am here. I do NOT want the application protocol
>>> to be proprietary. And the fact that we still don't have a standard keeps
>>> me from moving forward, because any development efforts I make may someday
>>> have to be rewritten once we do have a standard. IOW, I am not a big fan of
>>> reworking systems. I'd rather use open standards as early in the process as
>>> possible to facilitate interoperability later.
>>>
>>>
>>> > If the protocol was specified, then I could use ANY
>>> > server with the X3Daemon Client.
>>>
>>>
>>> Ideally, systems could interoperate, though there are other factors to
>>> consider. For example avatars must login to authenticate their identity and
>>> assets, consisting of information that may or may not be available to a
>>> third party server. But yes, you get the general idea.
>>>
>>>
>>>
>>>
>>> > It is not sufficient to specify the
>>> > fields and the behaviour of the NetworkSensor node. ...,
>>> > but I had the feeling that you want to
>>> > omit the specification of the protocol.
>>>
>>>
>>> Read again, I was referring specifically to network protocols. Still, at
>>> this early stage, I feel it may be a little premature to get too involved
>>> with an application protocol, that until we get a better grasp of what the
>>> requirements will be. For this reason, I am of the opinion that fields and
>>> events should be specified first. Just so that we have something to build
>>> upon.
>>>
>>> Of the published work available in that regard, we have BS Collaborate,
>>> DIS, and the Draft X3D Specification for NetworkSensor. I think the first
>>> step would be to take these, see what they have in common, and go from
>>> there for deeper analyses.
>>>
>>> Once we have that settled, IMO, only then should we turn to discuss an
>>> application layer protocol and its ramifications. GL
>>>
>>>
>>>
>>> > -----Original Message-----
>>> > From: x3d-public [mailto:x3d-public-bounces at web3d.org] On Behalf Of
>>> > Christoph Valentin
>>> > Sent: Friday, January 8, 2021 5:09 PM
>>> > To: X3D Graphics public mailing list
>>> > Subject: Re: [x3d-public] X3D and VRML for multiuser worlds
>>> >
>>> > Dear Gina Lauren
>>> >
>>> > Please find some feed back *inline*.
>>> >
>>> > Generally, please do not judge too hard, I'm not a native speaker and
>>> still
>>> > some of my wordings do not fit to the real intention.
>>> >
>>> > Kind regards,
>>> > Christoph
>>> >
>>> >
>>> >
>>> >
>>> ------------------------------------------------------------------------
>>> > >You want to lock in your users. That's not the spirit of open source.
>>> >
>>> > For once I was beginning to open up about the inner workings of a
>>> multiuser
>>> > system, but surprisingly, you apparently don't want to hear about it.
>>> It is
>>> > difficult to talk about open standards for a NSN if we can't refer to
>>> > actual implementations. It's not like there are a lot of them around..
>>> > [CV]: I should not have written this. However, I was a little bit
>>> > impatient, because I have been preaching for years and years that the
>>> > protocol itself must be specified. It is not sufficient to specify the
>>> > fields and the behaviour of the NetworkSensor node. Maybe I did not
>>> read
>>> > your words sufficiently thoroughly, but I had the feeling that you
>>> want to
>>> > omit the specification of the protocol.
>>> >
>>> > Also, who said anything about open source being a requirement? I was
>>> > actually volunteering closed source information for the benefit of an
>>> open
>>> > standard. If you can't see that I was actually "giving" something to
>>> the
>>> > community.. then perhaps I am wasting my time???
>>> > [CV]: Here I used "open source" and meant "open protocols", sorry, my
>>> > mistake. And, yes, I also "gave" a lot. Using too much time for my
>>> hobbies,
>>> > was one major reason, why my wife left us in 2015 (afterwards the
>>> SrrTrains
>>> > v0.01 project fell into hibernation mode due to lack of resources).
>>> >
>>> > Finally, if you would like to discuss an application layer protocol,
>>> maybe
>>> > look into work that has been done in the past referred to as vrtp and
>>> x3dp.
>>> > Not much, but a starting point. So far I have only heard vague comments
>>> > about SCTP, UDP, etc. (see below)
>>> > [CV]: I am sure that many people have contributed many parts of the
>>> puzzle.
>>> > Now we need somebody, who fits all together (that's not me, is it?)
>>> >
>>> ------------------------------------------------------------------------
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> ------------------------------------------------------------------------
>>> > > [CV]: I never suggested to specifiy the transport protocol (http,
>>> rtp,
>>> > > sctp, tcp, msrp, sip, xmpp, ........).
>>> >
>>> > hhhmmm.. I'm confused, what is this about???
>>> > [CV]: Let's assume, we specify an "Application Layer Protocol" (let's
>>> call
>>> > it ALP in the sense of a "working title"). Probably the ALP will
>>> consist of
>>> > the definition of a few PDUs (e.g. in XML, JSON, YAML or similar
>>> syntax).
>>> > Now we have to define, how the PDUs have to be transmitted over the
>>> > network. Will they be sent as payload in http messages (in the body)?
>>> Will
>>> > they be sent as payload in SIP messages (in the body)? Will they be
>>> sent
>>> > directly over tcp connections?
>>> > To get historically: at the beginning of the IETF they had a great
>>> > movement. You could get T-Shirts with the meme "IP over everything". IP
>>> > should connect any network with any network, building the
>>> Inter-network. So
>>> > they had to write one RFC for each L2 protocol in order to specify,
>>> how IP
>>> > has to be transported over any L2 link/network.
>>> > I am dreaming of an "ALP over everything" movement.
>>> >
>>> >
>>> ------------------------------------------------------------------------
>>> >
>>> >
>>> >
>>> >
>>> ------------------------------------------------------------------------
>>> > >[CV]: SCTP and UDP are members of the TCP/IP protocol family. UDP is
>>> as
>>> > >old as TCP, just simpler. SCTP is younger. It tries to merge
>>> advantages
>>> > >of both TCP and UDP and was originally invented to transport SS7
>>> protocols
>>> > >(SIGTRAN). SCTP supports 64k streams per association, what perfectly
>>> fits
>>> > >to our needs, imho
>>> >
>>> > Why are you trying to lecture me about network protocols? And what is
>>> it
>>> > exactly that you are saying or not saying, I find rather perplexing and
>>> > fail to see the relevancy. Let's keep going...
>>> > [CV]: I thought you wrote "SCTP is not TCP/IP". I want to stress that
>>> SCTP
>>> > actually IS TCP/IP
>>> >
>>> ------------------------------------------------------------------------
>>> >
>>> >
>>> >
>>> >
>>> ------------------------------------------------------------------------
>>> > >[CV]: Actually I suggested to specifiy ONE AND ONLY ONE application
>>> layer
>>> > protocol,
>>> >
>>> > No-one is questioning this as far as I know. Isn't that precisely what
>>> we
>>> > are trying to do?
>>> > Why are you augmenting this in my comments?
>>> >
>>> > [CV]: (see above) Maybe I did not read your words sufficiently
>>> thoroughly,
>>> > but I had the feeling that you want to omit the specification of the
>>> > protocol.
>>> >
>>> ------------------------------------------------------------------------
>>> >
>>> >
>>> >
>>> >
>>> ------------------------------------------------------------------------
>>> > >[CV]: The API (i.e Network Sensor) must be specified to run ONE
>>> content
>>> > with ANY X3D Player.
>>> >
>>> > Let's be careful here. The X3D player does not necessarily need to have
>>> > agency over the application protocol. For example the X3Daemon client
>>> > (sorry to bring it up) is entirely separate from the player other than
>>> for
>>> > interpreting ECMAScripts and rendering the results to screen. IOW, the
>>> > X3Daemon client can theoretically run in any X3D player, regardless of
>>> > internal multiuser coding, as long as ECMAScript (JavaScript) is
>>> supported.
>>> > This makes it very easy for authors to script avatar and object
>>> behaviors,
>>> > since it provides direct access to X3D nodes. It is also a reason why
>>> we
>>> > need to define a NetworkSensor node as part of the X3D standard.
>>> > [CV]: That's exactly what I am saying: you specified your X3Daemon
>>> client
>>> > API, so a content that uses that API, can theoretically run with ANY
>>> X3D
>>> > Player (that the X3Daemon client supports). If we specify a general
>>> Network
>>> > Sensor API, then content can run with any X3D Player that supports the
>>> > Network Sensor API.
>>> > However, if I use the X3Daemon Client API, then I MUST use the X3Daemon
>>> > Server, because the protocol is proprietary. If the protocol was
>>> specified,
>>> > then I could use ANY server with the X3Daemon Client. It's similar
>>> with BS
>>> > Contact and BS Collaborate.
>>> > Most customers are very sensitive about getting locked in. No matter if
>>> > open source or closed source. We (my employer) made this experience
>>> with
>>> > railway operators, too.
>>> >
>>> ------------------------------------------------------------------------
>>> >
>>> >
>>> > GL
>>> >
>>> > ________________________________________________________
>>> > * * * Interactive Multimedia - Internet Management * * *
>>> > * * Virtual Reality -- Application Programming * *
>>> > * 3D Net Productions 3dnetproductions.com *
>>> >
>>> >
>>>
>>>
>>>
>>> _______________________________________________
>>> x3d-public mailing list
>>> 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
>>> _______________________________________________ x3d-public mailing list
>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20210110/33142507/attachment-0001.html>