Re: HTTP in JSON Binary Encoding / Data Model

[Phillip Hallam-Baker <[e-mail]>]

On Wed, May 29, 2013 at 12:44 PM, James M Snell <[e-mail]> wrote:

> I understand what you're getting at and understand the motivations
> behind it. A few comments however...
>
> 1. Having a clear separation between Protocol and Application
> Semantics is a Good Thing.
>

Agreed. But the issue is whether to use a different syntax.

I would imagine that the JSON encoding would look something like:

Object: HTTP-Message
    List [Object] Headers
    Object  Content
        List [Object] Metadata
        Binary  Content

So the content would still be a binary blob as far ass HTTPdom goes. But
the same parser could break apart the envelope and the contents for a web
service.



> 2. By adopting the "Typed Header Codecs" I have proposed, it would be
> possible to use raw binary values in headers that specifically allow
> for it, which would make it possible to use the proposed "binary json"
> type encoding directly without further protocol modifications and
> without sacrificing backwards compatibility or requiring additional,
> undue complexity.
>

Yeah, it is quite possible that the way to go forward here would be to wait
to see what the HTTP group does and then back port some of that to JSON to
create a binary encoding scheme.

At the very least it would be nice to have a consistent approach. I still
loathe the idea of pushing stuff through libgzip if that is still being
considered.



> 3. While I'm sure there is room for improvement in the typed header
> codecs I've proposed, we have already had a number of conversations on
> the list about data model requirements for http headers. In my
> interpretation (for what it's worth), there was consensus around only
> requiring strings, integers, dates and raw binary as data types, with
> a clear backwards-compatibility story for http/1 and no need for
> anything as expressive as JSON at the protocol level.


Again, the flow of action might be in the opposite direction. Take the HTTP
work and use it to inform a JSON encoding.

That would probably mean we end up with two different encodings for the two
layers. But that is not necessarily a disaster if they take compatible
approaches.


I did initially consider a date type because that is something I define in
my protocol synthesizer/JSON schema tool. Then I removed it as a
distraction. Might be an idea to add it back again as time is a very common
data type for protocols.


-- 
Website: http://hallambaker.com/