Operation serialization (or, why do we need DataMember)
Options
I understand the need to squeeze an RPC into a single byte, but not so much why the properties/fields need to do the same. If an operation uses a hashtable as its backing, why not sequentially serialize the marked properties to the table? Why a readable lookup code?
0
Comments
-
because binary serialization does not exist on half the supported client platforms and for the other half there is no way to do it in a form that would work for all and even less performant and automatic. Some not even have the concept of classes.
Hence the byte key + binarydata per value blob which works on every platform that has a concept similar to hashmap which is about every platform.0 -
I'm away of this, but do the codes themselves offer anything other than convenience? I mean, does Photon use them to mash a bunch of messages together so that it can separate them back out? Does it use them to cache the type serialization? etc. It's just not very clear.0
-
The codes themself are really just there for convenience as it leads to cleaner, better maintainable code that way than with bytes directly
You can reuse the same codes for different purposes by the way, the only relevant thing is that they are not reused on the same operation.0 -
We went through several options and kept the codes when we switched from v2 to v3. It's efficient (size-wise), well defined (parameters have ids instead of relying on order of them) and is one simple way to allow optional parameters.
It doesn't affect message aggregation or caching.0 -
Ok great! I've got a T4 template generating all my codes so now I know they're in RPC scope and arent type specific or anything, I can pack more in.0
-
By the way: At several places, we pass on bytes instead of actual enum-typed values. The reasoning here is that developers have to add their own codes for events, operations, etc.
Glad to read you can cope with that.0
