Message-specific encoding and decoding

[nickng]

Background

In the current design, a formatter is specified during the connection creation, and all messages going through the connection will use the same formatter/serialiser. This makes sense for most generic message passing use cases as the formatting uses gob or other generic serialisation package.

However, custom message signatures in Scribble (for example, messages for HTTP communication) often need to use special encodings (HTTP: ascii-based+\r\n), and the encoding is more associated to the message rather than the channel itself -- for instance, different kinds of HTTP request may encode the message slightly differently (although it is still possible to use a one-size-fit-all HTTP encoding).

Proposal

The proposal here is to change the design in the runtime such that:

• Connection creation does not need to specify a formatter
• A default connector is used depending on the transport -- gob+TCP / pointer passing+shared memory
• If a message (of ScribMessage type) happens to have an Encode method -- or better, implements an interface that contains an Encode method, then use that to encode the message instead (similarly for Decode)

There is still a need to hook a ScribMessageFormatter to a given BinChannel connection (currently the Wrap method of ScribMessageFormatter), but could be done on-demand or otherwise. Having sane defaults but configurable if needed will make life easier for users of the API.

[rhu1]

My initial comments.

We can provide a base formatter (in the current style of formatters) that is implemented by default to dispatch to message-specific formatting routines.

The dispatch by this base formatter to the message-specific routines does not sound more costly than the proposed run-time check of "does the message have an Encode method or implement the interface".

We can offer an optimised version of the "formatter-dispatcher" that requires that all messages communicated using such a formatter implement a particular interface (with appropriate encode/decode methods), similarly as described above. Then no extra run-time dispatch check is required. (In general, I don't care too much about such a small cost though, anwyay.)

This approach sounds like less work than the full proposal given the current framework, so may be a pragmatic solution for the short term. This approach is also basically how the Scribble-Java framework works.