Currently there are two types of entities which SharpRemote can deal with: POD (Plain old data) and reference types.
When POD types are passed between endpoints, the entire data structure is serialized and sent over the wire
When reference types are passed between endpoints, then only an ID is sent over the wire, but every method call / property accessor causes additional remote procedure calls (which in the case of properties are blocking)
There might be room for a third kind of data type, which I hereby name Synchronized POD types. These types are basically a mixture of the two above "extremes": Both endpoints have a copy of the object graph and SharpRemote is responsible for eventually synchronizing changes between endpoints. The gist of this is that this synchronization isn't synchronous, but asynchronous and reading properties does NOT incur new remote procedure calls.
Obviously such an approach can only work if there is exactly one writer and one (or possibly more) readers, however should allow for an easier exchange of more complex object graphs than either of the two existing methods of sharing data.
Currently there are two types of entities which SharpRemote can deal with: POD (Plain old data) and reference types.
There might be room for a third kind of data type, which I hereby name Synchronized POD types. These types are basically a mixture of the two above "extremes": Both endpoints have a copy of the object graph and SharpRemote is responsible for eventually synchronizing changes between endpoints. The gist of this is that this synchronization isn't synchronous, but asynchronous and reading properties does NOT incur new remote procedure calls.
Obviously such an approach can only work if there is exactly one writer and one (or possibly more) readers, however should allow for an easier exchange of more complex object graphs than either of the two existing methods of sharing data.