visionmedia/super-sockets — pull request #6 by gjohnson (2012-07-31 12:56:52+00:00)
Title: Multipart Messages

This this adds quite a bit of changes, but most of it was just moving things around in order to help the multipart stuff fit in well. The bigger changes are outlined below.

### Protocol
For now, this just simply checks for a `meta` frame of "0" to know if it's a multipart message. I bumped the initial `codec.id` to "1" as a result. This leaves 1-9 for codecs.

### Encoder/Decoder instead of Parser

This is basically the `Parser` broken out into two different modules. Since multipart packing of messages required a little state for buffering, it got kinda awkward trying to work it into the existing dual purpose `Parser`.

#### Encoder
So now, `Encoder` is used to only pack messages. It's API can be seen [here](https://github.com/gjohnson/super-sockets/blob/multipart/test/test.encoder.js#L28)

The encoder knows very little about the codecs, you just pass `pack()` data and the codec id.This was needed because a multipart message might span multiple codecs (e.g pub topic and the pub body, etc.), so I moved the concept of `.format(type)` to stay just in the `Queue` for now.

#### Decoder
This is basically the same thing that `Parser` used to be (minus the .pack).

I kept getting tripped up referring to the first 4 bytes as "meta" and also having the first byte being known as "meta", so I dubbed those 4 bytes as "headers" to make it a little more clear.

The decoding of multipart messages is all in [`Decoder#parseBody`](https://github.com/gjohnson/super-sockets/blob/multipart/lib/decoder.js#L146). It's not the most elegant thing in the world, but I was having trouble picturing a cleaner way to do it... Any of your thoughts on it would be apreciated.

I think thats it? Sorry for the novel (again) lol.