search

reTHINK-project / specs

You'll find here the full detailed specification of reTHINK Framework
Apache License 2.0
3 stars 3 forks source link

proposal for simplification of the "connection" data object #8

Closed sdruesedow closed 7 years ago

sdruesedow commented 7 years ago

Currently the connection data object is expected to contain connection data either in "ownerPeer" or "Peer", depending on the hyperties caller/callee-role in the communication. The Hyperty therefore must take a lot of care at which place to put its local descriptions into the reporter object and from wich place to read the remote descriptions from the observed object, depending on its role as caller or callee.

This seems to be semantical overload, since it is clear at any time that the remote data is always in the observed object and the local data is always in the reported object - no matter which caller/callee-role the hyperty plays in the communication.

My proposal is to get rid of "ownerPeer" and "Peer" and to introduce a common field (e.g. "PCData") which will then hold the connectionDescription and iceCandidates. The hyperty would always simply write its local PC data into the reporterObject.PCData and read the remote data from observerObject.PCData. No need to handle un-symetric objects anymore.

The only information that would potentially get lost in the dataModel is the originator of the call, but this is IMO an information belonging to a higher layer. It is present in the involved hyperties anyways and could also be derived from the "type" of the SDP ("offer"/"answer") in the PCData.

pchainho commented 7 years ago

I agree with this simplification. Would the model below look like what you had in mind?

connection-data-object-model-new

sdruesedow commented 7 years ago

Yes this looks straight-forward. It is even simpler than my proposal. We have to take care with case-sensitivity. I noticed that in the current implementations the keys "iceCandidates, connectionDescription" etc. did not start with capital letters, which caused interoperability problems in the beginning.

sdruesedow commented 7 years ago

I pushed an updated version of the dtwebrtc hyperty to branch "connector-model" of dev-hyperty (https://github.com/reTHINK-project/dev-hyperty/tree/connector-model). This change is not active yet in the DT testbeds.