On Thu, Sep 11, 2014 at 1:14 PM, Stephan Beal <sgb...@googlemail.com> wrote:
> On Thu, Sep 11, 2014 at 7:03 PM, Ron W <ronw.m...@gmail.com> wrote:
>
>> As best I can determine, Fossil already demands that whomever adds custom
>> fields take responsibility for the customized New Ticket, View Tick and
>> Edit Ticket pages and associated TH1 apply the semantics correctly and
>> consistently.
>>
>
> But the JSON API has no mechanism for the user to take over.
>
I do not expect the JSON API to have such a mechanism.
If I write a client program that uses the JSON API to access tickets in
Fossil, it is my responsibility to make sure my program handles my custom
fields correctly.
No different than my TH1 code being my responsibility to make sure it
handles my custom fields correctly.
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).
So, the JSON API would not need to know or care about correct use of the
custom fields. The client using the JSON API would be responsible for using
the custom fields correctly.
>
> What, like this?
>
> [odroid@host:~/fossil/cwal]$ f json query -sql 'select count(*) from user'
> {
> "fossil":"d600c9f85421c0972231561560cb8410589c9606",
> "timestamp":1410455421,
> "command":"query",
> "procTimeUs":5000,
> "procTimeMs":5,
> "payload":{
> "columns":["count(*)"],
> "rows":[{"count(*)":5}]
> },
> "g":{
>
Is this possible through the web interface? If so, can it be disabled?
> Any integration that required more than this would allow should either
>> interact with the Fossil CLI or use libfossil.
>>
>
> So far i've been punting on the "ticket problem" in libfossil too because
> of the tight connection between tickets and th1. i really don't want
> libfossil to have _any_ built-in scripting language, because no language is
> a perfect fit. Still not yet sure what's going to happen in that corner of
> the code.
>
It just means that any app (or other library) using libfossil to access
tickets will have to be held responsible for using the custom fields
correctly. libfossil would only provide the means to access the tickets and
their fields. No validation beyond limiting string lengths. Nor any mapping
of queries or updates.
(From above) By appropriate mapping, I suggest something like:
Query JSON message: Payload is 2 lists: One of name/value pairs designating
the fields to search and describing the values to match. The other a list
of fields to return in the results.
Update/Add JSON message: Payload is a list of name value pairs designating
the fields and their values.
The response could be either just a string containing the "raw" response,
or a list of name/value pairs.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
