On Sun, Sep 11, 2011 at 4:19 AM, Clark Christensen <cdcmi...@yahoo.com>wrote:
> In my experience writing both JSON web services (in Perl), and the
> consumers of those services, sometimes you can get output that contains not
> only a JSON string, but stray newlines or other (debugging?) output. I'm
> sure you and Fossil would never do such a thing, right? Then again,
> anything's possible (useful debugging output, ISP-modified content, etc.)
>
At the moment it's very possible that some of Fossil's console-/html-mode
text slips free, but as i add/refactor the JSON code i'm making sure that no
non-JSON goes to stdout. There might still be places where stderr output
goes, but i _think_ that Apache sends those to the error log. My demo/test
app literally won't work if a given command produces invalid JSON, so it's
unlikely that any non-JSON output will slip through during testing.
This makes it difficult to parse the JSON string out of the response
> content. I have
>
You don't need to parse it yourself (or i never do). Use
JSON.parse(theInput) or equivalent for the client side. e.g. using the C
JSON API it looks like:
cson_value * root = NULL;
int rc = cson_parse_FILE( &root, stdin, NULL );
if( 0 == rc ) { /* success */ assert(NULL != root); ... }
The root JSON can be either an array or object, but the fossil API uses only
Objects for the root nodes.
As a client, if the server generates invalid JSON then the client is out of
luck. The best we can do here is make sure that fossil/json emits no
non-JSON.
> found that surrounding the JSON string with a predefined tag (I've
> standardized on <TJSON></TJSON>; because my company's name starts with "T",
> but Text-JSON works, too) makes it easy to extract the JSON string from
> whatever else might be in the response content.
>
But it also makes it invalid JSON. :-?
> Also, as part of what I've come to call the "TJSON" format, the JSON always
> includes a status object where a result code and message can be
> transmitted. So, in TJSON, the minimum response would always look like:
>
> <TJSON>{"RC":{"code":0,"msg":"Success"}, "fossil":{...}}</TJSON>
>
That's exactly what i've been doing in the majority of my JSON lib
(including this one) - an outer envelope with result code/text and an inner
payload object with response-specific data.
All of the other properties of the JSON object are arbitrary based on the
> requirements of the requested service method.
>
Right. To avoid muddling up the envelope i've decided for this impl that the
request-specific args always go in the payload property of the envelope,
leaving us free to expand the envelope definition without colliding with
command-specific properties. Because of how the underlying API works, it's
also trivial to pass most request-specific options as GET parameters
(provided they're not too big).
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
