Talk:Problems with current IPC

Erik Massop edited this page Nov 4, 2017 · 1 revision

gssons wishlist:

Just throwing some thoughts out there...not all of it is very thought through, but might just provoke someone to do the thinking for me :)

The serialization pseudo-structure might need some explaining:

name : type - the normal way of defining an entry {...} - a structure {...}[n] - an array of 'n' structures v : Type(t) - a value v of the type indicated by the value t.

Introducing the convenience type TypedValue:

{   type_id : integer,   value   : Type(type_id) }

and string:

{   length  : integer,   value   : char[length] // utf-8 chars, naturally }


{   count : integer, // Number of tuples   {     key         : string,     typed_value : TypedValue // TypedValue is a <type, value> tuple   } [count] }


Having a multiple typed list is usually a bad idea since, when different types are actually used, an implicit structure that is identified either by order (hard to extend) or type (only one element of each type). If a multi-typed list is used, what is probably really desired is a dict or a combination of list and dict.

{   count : integer // number of entries   type_id  : integer // type of list entries   value[count] : Type(type_id) // 'count' entries of type 'type'. }


  • Error packets carries a typed value, perhaps some error type, so that they can look like 'normal' packets, and be handled as such on lower layers.
  • Serialization of types goes symmetric, ie. same data is sent in the same way no matter if it goes to or from the server. One of the directions currently does not use the 'type-tags' or whatever the proper name might be :). It would be really neat to be able to create packet representations in the same way in all situations.
Clone this wiki locally
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.