Add support for more Encoders

[mcdonnelldean]

Encoding should be configurable, obviously this has an impact on the implicit schema checking code. Proposed encoders are:

• Vanilla JSON
• MsgpackV5

Do we need any more? Should be support XML?

[mcollina]

How about we should support any encoder/decoder that is compatible with levelup, using the same api:

https://github.com/mafintosh/protocol-buffers#leveldb-encoding-compatibility https://github.com/mcollina/msgpack5#levelup-support

[mcdonnelldean]

Sounds good. What about the issue of schema's, we currently match against Protobuf's schema.

[mcollina]

Basically whatever you put into hyper.message that has an encode and decode function should work, as in levelup.

[mcdonnelldean]

That's not how we are doing the schema check though, unless I misunderstand. We are using protobouf's object directly and checking it like an array:

https://github.com/mcollina/hyperemitter/blob/master/hyperemitter.js#L109-L116

[mcollina]

yes, but if it quacks like a duck, it's a duck. messages is a Object, with each property being a supported event. In that object, all properties are Object themselves that have an encode() https://github.com/mcollina/hyperemitter/blob/master/hyperemitter.js#L120 and decode() https://github.com/mcollina/hyperemitter/blob/master/hyperemitter.js#L297

[mcdonnelldean]

This assumes we have an object sent to us in that shape. So in the case say msgpack to we provide an interface their to export all types so the user doesn't have to do the transform themselves? Interestingly this would open up HyperEmitter to have different encoders on a per message basis.

[mcdonnelldean]

Also perhaps something like emitter.registerType(type)

[mcollina]

if you do:

hyper.messages.MyMsgPackMsg = msgpack()

you will be good to go.

[mcdonnelldean]

Ok, let me play with this tomorrow night and come up with a WIP PR to discuss.

[mcdonnelldean]

Started with #15

[mcollina]

Implemented in 1.2.0.