On 3/14/2017 3:06 PM, Stefan Bellon wrote:
On Mon, 13 Mar, Ross Berteig wrote:
When fossil is configured to include JSON support it has a fossil
json command that consumes a JSON object full of command and
arguments and returns a JSON object of results. A similar feature is
available over HTTP(S) through URLs beginning with /json.
Ah, that's why I never got JSON to work. The input to the JSON support
is via JSON object as well?! I always assumed you can just use ordinary
command line and specify something like --json to tell fossil to output
the result of the command as a JSON object.
The JSON API originated as a JSON over HTTP, but a mapping between URLs
and the command line made sense for debugging. So it can be used through
the fossil json command by a fairly direct mapping from /json... URLs
used for GET and POST. HTTP POST allows the submission of a command
packet rather than fitting everything into the URL.POST data can also be
simulated from the command line, from either a file or stdin.
The output is a JSON object that contains metadata about the fossil
instance and the command success or failure, as well as the result of
the command.
The documentation is not rolled into the fossil documentation as yet.
You can find it on Google Docs: https://goo.gl/Iv8OFL
The original use cases were all of the web app flavor, hence the
emphasis on HTTP in the docs, with the CLI support more of an
after-thought. I suspect that is why a --json global option was not
considered at all.
Here's a sample of output for the timeline, limited to the latest two
checkins:
C:...>fossil json timeline checkin --limit 2
{
"fossil":"38115a0bd96c3788e36506b965f938bd31f0d0b65cf26dd7866abefb80a9a15d",
"timestamp":1489530880,
"command":"timeline/checkin",
"procTimeUs":0,
"procTimeMs":0,
"payload":{
"limit":2,
"timeline":[
{
"type":"checkin",
"uuid":"38115a0bd96c3788e36506b965f938bd31f0d0b65cf26dd7866abefb80a9a15d",
"isLeaf":true,
"timestamp":1489526151,
"user":"rberteig",
"comment":"Update hash regexp to defend
against full length SHA3 hashes.",
"parents":["f92672bda33bf86752053272ef1f7aa9de088e823b9a864877042c2b8802800b"],
"tags":["trunk"]
},
{
"type":"checkin",
"uuid":"f92672bda33bf86752053272ef1f7aa9de088e823b9a864877042c2b8802800b",
"isLeaf":false,
"timestamp":1489522870,
"user":"rberteig",
"comment":"New test case for the
Markdown bug, fixed issues with hash matching, fixed tests for the
TH1 unversioned command so they no longer depend on unversioned files
from a past release in the real repository.",
"parents":["dd41f85acf57290aba64c1f42ddeafcdf80432df80a07cea699bbb7456ff1386"],
"tags":["trunk"]
}
]
}
}
You'll notice that the SHA3 hashes simply slot in place where SHA1 had
been without the format changing.
....
Is there a reason that the default builds as available for download
have JSON support not enabled?
We've discussed this in the past, and there hasn't been a strong
advocate for enabling it by default. It does increase the attack surface
for fossil as CGI to some degree. Until I started writing test cases for
it, it wasn't covered at all by the internal test suite. I know the lack
of testing was a big concern. I've increased its coverage from "none" to
"some", but I can't claim that the JSON support is well covered by the
tests yet. Most features only have tests that confirm the feature is
present and got a correct answer, with no attempt to probe at edges and
errors.
Maybe it is time to bring that discussion back up.
Also, not every command is available via JSON, and I suspect that
there is no JSON equivalent to fossil annotate. If we can figure out
how to represent the annotate/blame/praise data in JSON, then adding
it should be possible.
I can tell you how JSON output of IBM Rational Team Concert (which is a
complete mess, but has wonderful JSON output) looks like for the
annotate command for a specific file:
{
"annotations": [
{
"author": "author of commit changing line 1 last",
"comment": "commit message of commit changing line 1 last",
"line": "file content of line 1",
"line-no": "1",
"modified": "timestamp of commit changing line 1 last",
"uuid": "revision hash of commit changing line 1 last",
},
{
"author": "author of commit changing line 2 last",
"comment": "commit message of commit changing line 2 last",
"line": "file content of line 2",
"line-no": "2",
"modified": "timestamp of commit changing line 2 last",
"uuid": "revision hash of commit changing line 2 last",
},
{
"author": "author of commit changing line 3 last",
"comment": "commit message of commit changing line 3 last",
"line": "file content of line 3",
"line-no": "3",
"modified": "timestamp of commit changing line 3 last",
"uuid": "revision hash of commit changing line 3 last",
},
...
]
}
Certainly wordy, but effective. And a clear advantage of JSON over
annotate, blame, and praise is that all the metadata can be provided for
each line. I don't know enough about what the datastructures look like
inside the existing fossil annotate commands, but if we can do those, we
can certainly do something like this.
--
Ross Berteig r...@cheshireeng.com
Cheshire Engineering Corp. http://www.CheshireEng.com/
+1 626 303 1602
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
