Binary event

[flowersinthesand]

Cettia transport can carry binary data but how to make use of it for socket has not been yet determined. With this feature, you will be able to exchange events whose data is binary without binary-to-text conversion.

There are two ways to implement the feature:

1. Introduce our own event object format.
   It defines how each byte or character should be transferred to describe an event.
2. Describe event object by reusing existing data format for binary.
   It requires a binary interchange format.

Here's the Event interface described in WebIDL:

[Constructor]
interface Event {
  readonly attribute string id;
  readonly attribute string type;
  readonly attribute any data;
  readonly attribute boolean reply;
};

I'm inclined to choose 2nd option. Because, brand new protocol would be a barrier to implement it in other languages comparing to use existing other text interchange format and binary interchange format with some restrictions, and also that data format can be a replaceable building block, where it allows for user to replace with other one on demand. BTW, it's possible to implement 1st option by redefining that building block of 2nd option.

The binary data format should meet the followings like JSON:

• It should be able to describe any (schema-less) type value.
• It should be widely adopted and available in browser and Java.

Apart from implementation, two separate methods to determine whether to send a given arbitrary event as a text message or binary message, repsectively, are probably required. Also, there should be a guide for behavior of the default send method. If that guide is perfect, we may not need to provide separate methods.

To do:

• Find the default data format for binary.
• Think out the default behavior of send method.
  • Name two separate methods for this feature if the default behavior is not well defined.

[flowersinthesand]

Strong candidates for binary interchange format - BSON and MessagePack.

[flowersinthesand]

I decided to adopt MessagePack since it is dynamically typed, fast and compact as well as is ported in other many languages. Note that as mentioned above, this architecture can allow you to replace MessagePack, the default binary interchange format, with your favorite one.

The following dependencies will be used:

• https://github.com/kawanet/msgpack-lite for RI and JavaScript Client
• https://github.com/msgpack/msgpack-java for Java Server

As for the default behavior of send method, it can decide whether a given object should be serialized into either text or binary by its type. For example, Buffer or ArrayBuffer can be regarded as binary in JavaScript and byte array or ByteBuffer can be regarded as binary in Java.

Accordingly, I think first two separate methods to force a given object to be serialized into either text or binary are not needed now. Because, the current text interchange format, JSON, has no way to describe binary (It can be described as object or base64 encoded string by some contract but without that contract it's just either object or string) so forcing a given object to be serialized into text isn't meaningful. Forcing a given object to be serialized into binary may have the merits of space but in browser it should be decoded by custom JavaScript implementation not browser's native JSON implementation so it's unfit to add such method now.