On Fri, Sep 12, 2014 at 2:17 AM, Stephan Beal <[email protected]> wrote:

> On Thu, Sep 11, 2014 at 10:02 PM, Ron W <[email protected]> wrote:
>
>> No different than my TH1 code being my responsibility to make sure it
>> handles my custom fields correctly.
>>
>
> "handles" is the operative word. TH1 can _handle_ things, and JSON, by
> itself, cannot.
>

Nor does the JSON API need to handle "things". Even the "TH1 API" doesn't
handle things. It's the code using the API that does the handling


>
>
>> The only expectations of the JSON API would be to limit the length of
>> strings delivered to the rest of Fossil and map queries/updates
>> appropriately (see below).
>>
>
> Any such limits cannot be imposed until the JSON is parsed in its
> entirety, though. The JSON "DOM" (so to say) gets parsed at a lower level,
> and then the Fossil side of that has to understand what those limits are
> and where to apply them. e.g. it must not apply them in the Wiki APIs,
> where pages can be arbitrarily long.
>

To avoid buffer overflows. I would hope that the JSON API already does this.


> Why are string length limits so important here - i don't get that part.
> What if someone wants to add a "rough draft of your most recent novel"
> field?
>

Same as above, avoiding buffer overflows. If the API (and Fossil) can
handle a string the size of "Encyclopedia Galactica", that's great.

i'll need to see an example before that's clear to me, i think. Can you
> compose some pseudo-json for such a request/response exchange?
>

I guess something like:

"QUERY",                  // message type
"JiraId", "1234",        // query fields and values
"", "",                         // end of query
"*",                            // fields to include in response (in this
case, all)
""                              // end of message

Similar for "NEW" and "UPDATE" messages, except the second list of the just
field names not needed.

Then for the response, maybe just return the "raw" response as a string, or
a name/value list:

"QRESP", "ok",              // message type and response status
"TktID", "FossiIdHash"  // First field (maybe should always be Fossil's
identification for what is being sent)
"Title", "Summary of this ticket",
...
"", ""                              // end of message

Response for NEW or UPDATE would likely be just the type, status and the
Fossil Identification name/value pair, followed by the end of message
indicator.
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Reply via email to