On Fri, Sep 9, 2011 at 7:38 AM, Martin S. Weber ephae...@gmx.net wrote:
are talking about REST and JSON, but you really, really mean JSON
over HTTP. What I'm trying to say is that you seem more concerned
Yes, i am very possibly abusing some terminology. :/ Feel free to set me
straight.
-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 martin.we...@nist.govwrote:
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
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
On Fri, Sep 9, 2011 at 10:34 AM, Alaric Snell-Pym
ala...@snell-pym.org.ukwrote:
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?
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
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 21...there'll be no
problem.
That being said,
On Fri, Sep 9, 2011 at 6:35 PM, Martin S. Weber martin.we...@nist.govwrote:
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){
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
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 sgb...@googlemail.com wrote:
On Fri, Sep 9, 2011 at 7:11 PM, Ron Wilson ronw.m...@gmail.com 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
On Fri, Sep 9, 2011 at 7:42 PM, Stephan Beal sgb...@googlemail.com wrote:
On Fri, Sep 9, 2011 at 7:11 PM, Ron Wilson ronw.m...@gmail.com 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
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,
On Fri, Sep 9, 2011 at 8:46 PM, Martin S. Weber martin.we...@nist.govwrote:
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
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 a page have tags???
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/
15 matches
Mail list logo