[x3d-public] X3D and VRML for multiuser worlds
GL
info at 3dnetproductions.com
Fri Jan 8 18:59:41 PST 2021
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20210108/a3f3ccd9/attachment.html>
More information about the x3d-public
mailing list