ztellman/gloss — pull request #13 by drsnyder (2012-08-14 03:17:47+00:00)
Title: POC: Support for selecting delimiter at encode time based on the string being encoded

Hi Zach,
This is to address the issue I was having with the memcache-like protocol in [this thread](https://groups.google.com/forum/?fromgroups#!topic/aleph-lib/JNNBSa5kjPs).

In some cases (like the memcache protocol or the beanstalkd protocol) you sequences of the following form simplified for brevity:

CMD TOKEN\r\n
TERM\r\n

In this case, a codec of the form

(compile-frame (header (string :utf-8 :delimiters [" " "\r\n"]) h->b b->h))

Will encode `CMD TOKEN\r\n` properly, but not `TERM\r\n` since `gloss.data.bytes.delimited` will use the first delimiter specified which is a " ". The latter will be encoded as `TERM ` with a trailing space instead of `\r\n`.

This pull request adds support for an :encode-with option that can be supplied to the string function. The :encode-with option is a function that takes the string being encoded and the delimiters (post translation) and returns the appropriate delimiter. See [the test case](https://github.com/drsnyder/gloss/blob/clj-1.3/test/gloss/test/core.clj#L212) for an example and the expected result.

This should allow the same codec to be used for encoding and decoding protocols where multiple delimiters are used depending on the context. The user will have more control over which delimiter should be used.

I'm calling this POC because I wanted you to take a look before I went any further. I only changed `delimited-codec` but I noticed that `delimited-bytes-codec` also takes the first delimiter when encoding. I'm happy to change that one as well if you approve of the change.

Thank you so much for building this suite of tools! I'm looking forward to your feedback.

Thanks,
Damon