[x3d-public] New X3D network working group suggestion: Standards forcollaboration I/O, processing and storage (SP-ARK)

[John Carlson]

I will review you contributions now Christoph.

John

Sent from Mail for Windows 10

From: Christoph Valentin
Sent: Sunday, March 31, 2019 2:47 PM
To: John Carlson; X3D Graphics public mailing list
Cc: Sven-Erik Tiberg
Subject: Aw: New X3D network working group suggestion: Standards forcollaboration I/O, processing and storage (SP-ARK)

John,

Of course I will add these ideas to the collection of inputs. 

>>>>>>>>What do you view as the primary SP-ARK actions?

1) SP-ARK is dedicated to the use (and support) of X3Dv4
2) basically, the playground is open to anybody, who is interested in simple multiuser scenes
3) probably we will implement some demo application maybe even a server (depends on support)
4) Goal 1: help the Web3D Consortium in defining an application layer protocol for the Network Sensor 
5) Goal 2: to be defined
6) Goal 3: to be defined
7) and so on

8) SP-ARK has not been started yet, but with this e-mail the probability of a start increases :-) 

All the best
Christoph

-- 
Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.
Am 31.03.19, 21:14, John Carlson <yottzumm at gmail.com> schrieb:
Way up above the networksensor protocol is the concept of collaborate.  How can we effectively store and communicate collaborations?  Do they effectively store to a typical hierarchical file system, ala Git or Google Docs or do we need to create a new technology for collaborations? Might collaborations be “part of the network”?  What if you couldn’t work without someone to collaborate with?   Can a collaboration include parts of the physical world?
 
Christoph, you can add this as a comment to SP-ARK.  I think we need to develop some use cases or user stories for SP-ARK that involve collaboration if they are not already there:
 
Primary actions are Create, Delete, Change, Inspect,  Add, Remove, Move, Copy, Grant, Revoke.   Record Date/Time for all actions performed.
 
Create Collaboration
Create Object
Create Subject
Delete Collaboration
Delete Object
Delete Subject
Change Collaboration
Change Object
Change Subject
Inspect Collaboration
Inspect Object
Inspect Subject
Add Subject to Collaboration
Add Object to Collaboration
Add Collaboration to Collaboration
Remove Subject from Collaboration
Remove Object from Collaboration
Remove Collaboration from Collaboration
Move Subject to Location, Orientation in Collaboration
Move Object to Location, Orientation in Collaboration
Copy Object between Collaborations
Copy Collaboration between Collaborations
Move Collaboration to Location, Orientation in Collaboration
Grant access to “Collaboration, Object, Action” (key) to Subject
Revoke access to “Collaboration, Object, Action” from Subject
 
So for pc.multiplayer, there are 3 collaborations, global tag, card game and chat, managed by a server.
Objects include location, card and message
Subjects are clients
There is no real collaboration, except the server is effectively a collaboration.  There is limited communication between servers.
No grant/revoke.
 
Collaboration might be thought of as a server, table, channel, room, or conversation all at once.
 
More?  I believe if we implement this much for a network protocol for SP-ARK, we will have achieved quite a bit.
 
We should probably prototype with an easy to use protocol, that can be used from JavaScript, and “upgrade” to a more industrial protocol once we have the patterns down. That is, lower levels can be swapped out by vendors. Thus we need a “JPA-like (Hibernate)” level which unifies the persistence and communication.  I am thinking some object attributes can be annotated as persistent and/or communicateable.
 
What do you view as the primary SP-ARK actions?
 
John
 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20190331/a488a8fa/attachment-0001.html>