Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Binary event #9

flowersinthesand opened this issue Feb 28, 2016 · 2 comments

Binary event #9

flowersinthesand opened this issue Feb 28, 2016 · 2 comments


Copy link

@flowersinthesand flowersinthesand commented Feb 28, 2016

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:

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.
Copy link
Member Author

@flowersinthesand flowersinthesand commented Feb 28, 2016

Strong candidates for binary interchange format - BSON and MessagePack.

Copy link
Member Author

@flowersinthesand flowersinthesand commented Mar 1, 2016

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:

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.

@flowersinthesand flowersinthesand mentioned this issue Mar 3, 2016
2 of 2 tasks complete
@flowersinthesand flowersinthesand added this to the 1.0.0-Alpha3 milestone Mar 3, 2016
@flowersinthesand flowersinthesand self-assigned this Feb 11, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.