Hi, all!
http://fossil.wanderinghorse.net/repos/fossil-sgb/json/
That's my test app for the JSON API. As new features/request types are added
you'll see them pop up there.
Happy Hacking!
--
- stephan beal
http://wanderinghorse.net/home/stephan/
_
Hi, all,
i'm looking for a fossil query which will give me the following data for a
wiki page:
{
"name":"PageName1",
"timestamp":int, /* Unix Epoch GMT of check-in */
"artifactId":"...",
"savedBy": "user name", /* can we do this easily? */
"tags": ["tag1", ..."tagN"], /* can
On Fri, Sep 9, 2011 at 8:46 PM, Martin S. Weber wrote:
> Actually, if the complete CLI functionality was available as JSON output,
> we'd automatically have our library/frontend model. Think about it, a
> library is a backend that you communicate with.
i agree with that, but actually using it th
On 09/09/11 14:15, Stephan Beal wrote:
(...) Even the wiki rendering is done on the client.
Beautiful. Having this the CLI could finally output text markup (aka wiki
markup) on the console instead of outputting HTML!
Regards,
-Martin
___
fossil-use
On 09/09/11 13:52, Stephan Beal wrote:
(...) While there
is arguably little use for JSON in CLI mode, i'm trying to keep it all
structured so that i can use the same code/commands in both CLI and
CGI/server modes (...)
Actually, if the complete CLI functionality was available as JSON output, we
On Fri, Sep 9, 2011 at 7:42 PM, Stephan Beal wrote:
> On Fri, Sep 9, 2011 at 7:11 PM, Ron Wilson wrote:
>
>> Also, I agree that HTTP status codes should be for transport rather
>> than application errors.
>>
>
> :-D. Okay, so there's 2 votes for that.
>
> In my experience (and i've written boatl
On Fri, Sep 9, 2011 at 11:18 AM, fossil-m...@h-rd.org
wrote:
> Please consider that when using cgi a complete REST over http style
> interface is not supported: cgi defines only http GET and POST
>
> DELETE and PUT are not in the cgi spec and handled differently by different
> httpd's.
fossil se
On Fri, Sep 9, 2011 at 7:11 PM, Ron Wilson wrote:
> Also, I agree that HTTP status codes should be for transport rather
> than application errors.
>
:-D. Okay, so there's 2 votes for that.
In my experience (and i've written boatloads of JS- and Java-based Ajax the
past 2 years), i find it more
On Fri, Sep 9, 2011 at 7:04 PM, Twylite wrote:
> e.g. "/timeline" produces HTML by default, but "/timeline.json" would
> return the same information in JSON.
>
i like that idea. i hadn't thought of simply using an extension. i don't
have a strong opinion as to whether, e.g. /json/stat or /stat.j
For me, making it easier to create an IDE plug-in for Fossil would be
the greatest benefit.
Also, I agree that HTTP status codes should be for transport rather
than application errors.
On Thu, Sep 8, 2011 at 4:01 PM, Stephan Beal wrote:
___
fossil-user
On 09:59 PM, fossil-m...@h-rd.org wrote:
Great idea!
Please consider that when using cgi a complete REST over http style
interface is not supported: cgi defines only http GET and POST
DELETE and PUT are not in the cgi spec and handled differently by
different
httpd's.
A common convention i
On Fri, Sep 9, 2011 at 6:34 PM, Martin S. Weber wrote:
> Really? I'm assuming the JSON output goes to stdout, and the error message
> goes to stderr. In that case it wouldn't interfere with the JSON output at
> all. Just pipe the output to your json reader without a 2>&1...there'll be
> no problem
On Fri, Sep 9, 2011 at 6:35 PM, Martin S. Weber wrote:
> That being said, of course a library should never write to stderr directly.
>
>
i just found the reason for it:
/* Error logs from SQLite */
void fossil_sqlite_log(void *notUsed, int iCode, const char *zErrmsg){
fossil_warning("%s: %s", s
On 09/09/11 12:34, Martin S. Weber wrote:
Really? I'm assuming the JSON output goes to stdout, and the error message
goes to stderr. In that case it wouldn't interfere with the JSON output at
all. Just pipe the output to your json reader without a 2>&1...there'll be no
problem.
That being said,
On 09/09/11 12:31, Stephan Beal wrote:
Maybe this is a bug, maybe not, but i've certainly never seen it before...
i'm intentionally introducing SQL errors to test my JSON-side error
handling, and i found that this:
rc = sqlite3_prepare_v2(g.db, zSql, -1, &pStmt->pStmt, 0);
outputs to stderr wh
Maybe this is a bug, maybe not, but i've certainly never seen it before...
i'm intentionally introducing SQL errors to test my JSON-side error
handling, and i found that this:
rc = sqlite3_prepare_v2(g.db, zSql, -1, &pStmt->pStmt, 0);
outputs to stderr when preparation fails.
i've never seen sq
On Fri, Sep 9, 2011 at 10:34 AM, Alaric Snell-Pym
wrote:
> What will this mean for the famed "single binary, just copy it into your
> PATH" effect? Will said single binary still exist and statically link
> libfossil into itself, but also have a libfossil.so available alongside?
>
A single-binary
Great idea!
Please consider that when using cgi a complete REST over http style
interface is not supported: cgi defines only http GET and POST
DELETE and PUT are not in the cgi spec and handled differently by different
httpd's.
___
fossil-users mail
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/08/2011 09:27 PM, Stephan Beal wrote:
> On Thu, Sep 8, 2011 at 10:11 PM, Martin S. Weber wrote:
>
>> On 09/08/11 16:01, Stephan Beal wrote:
>>
>>> 1) A split between library and app. i.e. libfossil vs. the fossil
>>> server/cgi/shell app(s)
>>>
>
19 matches
Mail list logo
