Using arbitrary x- subtypes is allowed but if this format ever leaves
experimental status we'd want to drop the x- and I don't think
application/json-stream is ideal, in particular because the only other
current use of the word stream in content types is
application/octet-streamwhich has no particular relationship to "streaming" as
we're using it
here. Digging through the various RFCs for mime types it's not exactly
clear what the best choice would be, but a literal reading of
http://www.ietf.org/rfc/rfc2046.txt suggests that it should definitely be
under application:
registered subtypes of "text", "image", "audio", and "video" should
not contain embedded information that is really of a different type.
Such compound formats should be represented using the "multipart" or
"application" types.
It might make sense to use *multipart/json* but to comply with the RFC
multipart types have to use line based delimeters (e.g. "--"), and the fact
that there are so few existing multipart types suggests IANA doesn't like
to give them out. Perhaps we could instead just borrow multipart's *
boundary* parameter to enhance *application/json*:
- application/json
- exactly one JSON object
- application/json; boundary=NL
- one or more JSON objects delimited by newlines (no newlines allowed
in object)
- application/json; boundary=CRNL
- one or more JSON objects delimited by carriage return/newline pairs
(newlines allowed in object)
As far as I can tell sending a single JSON object using any of these
formats won't break any existing parsers (they all seem to handle an extra
newline or carriage return/newline pair at the end without complaint, so
the choice of boundary would only matter when multiple objects were sent.
One could conceivably (ab)use this approach to handle other approaches,
such as Twitter's
delimited=length<https://dev.twitter.com/docs/streaming-apis/processing#delimited>option
- application/json; delimited=length
- multiple JSON objects, each prefixed with its length in bytes
(encoded as a string of base-10 digits)
but a single object sent in this form will not parse with a standard parser
(you'd have to strip off the length first) so it feels a bit off to me.
On Thursday, May 24, 2012 10:05:13 AM UTC-7, Tim Caswell wrote:
>
> application/x-json-stream -> JSON messages (without extra whitespace)
> newline separated.
>
> Several streaming json parsers support this already out of the box. They
> ignore the newlines and know when a json body ends because of the parser
> state. People who don't have a streaming parser, can search for the
> newline instead and do their own de-framing. Either way, it's very trivial
> to parse.
>
>
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
