Envelopes - objects vs array

[cayuu]

So the (last?) major change to the Qe spec was to shift it into a significantly ordered structure, such that it could be represented in a list without requiring a key-hash. The keys, however, remain in the spec because it's useful at a human-level to deal with Qe as a keyed object than as an ordered list.

The important point is this: the structure is now at release candidate stage. All of the major issues have been worked out and otherwise defined. What remains now is really a question of encoding.

• Keyed hash vs
• list.
• Vs maybe a sparse ordered object.

Or in other words (serialised as JSON):

{ "do":"find", "on":"posts", "limit":25 } // Keyed hash
["find","posts",null,null,null,null,null,null,25] // List
{0:"find", 1:"posts", 8:25} // sparse object

Settling on an encoding is bothersome. Code to consume each of these could more or less end up in the same place with little to no overhead.

if (!qe.do) .. // keyed hash
if (!qe[0]) .. // list
if (!qe[0]) .. // sparse object
// A list of constants: eg. `DO` = 0 would enable for list & sparse:
qe[ DO ]
// And passing the raw Qe through a `new Qe( rawqe )` could always end up here:
qe.do // looks up qe[0]
// Plus a bunch of other approaches and tricks...

So the encoding doesn't really seem to matter.

It comes down to performance. Bytes OTW. Memory footprints. Speed in serialising/deserialising. And for this we need big ol tests.

[cayuu]

Qe implementations need a clear answer to this. Are Qe hash tables or lists? Allowing both in the spec requires that implementations test every Qe's type, and:

• write branched code handling each style, or;
• manually parse Qe to the more readable format (a toQe() lib), or;
• wrap the Qe in a generic accessor

All this is processing overhead for every message. This needs testing.

From a writing and reading code perspective, the declarative keyed object approach is MUCH nicer than referencing indices eg. mylocalqeref[ 5 ]. Inspecting Qe makes much more human sense with keys.

Significantly ordered lists allow for (in theory) smaller footprints. It may be preferable to retain the significant ordering in the spec for serialisation purposes, while recommending the object hash fields as the deserialised target.

Concerns + thoughts:

• Size of message packets over the wire and in memory
• Speed of access (especially if additional serialisation/deserialisation required)
• Ease of maintainability (more human readable)

[cayuu]

Coding using Qe has been an exercise in exclusively using the object model (rather than some serialised version). They're easy to write, easy to remember, easy to use. Using an ordered list for this, or some other abstraction is overkill.

Maintaining the significant order is still worthwhile, as it allows transports to use their own serialisation if needed. Lets see if that ever required.

Next: Remove the "list style" examples, retain the significant ordering and settle on object hash structure.