Talk:Problems with current IPC

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 }

XMMS_OBJECT_CMD_ARG_DICT:

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

XMMS_OBJECT_CMD_ARG_LIST:

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'. }

Misc:

• XMMS_OBJECT_CMD_ARG_UINT32 dies.
• 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.