On Sep 9, 2011, at 7:35 PM, Stephan Beal wrote:
> 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
>
___
From: Stephan Beal <sgb...@googlemail.com>
To: fossil-users@lists.fossil-scm.org
Sent: Friday, September 9, 2011 12:02 PM
Subject: Re: [fossil-users] Draft doc for JSON/REST Fossil interface
On Fri, Sep 9, 2011 at 8:46 PM, Martin S. Weber <martin.we...@nist.gov>
wrote:
Actually,
>Also, I agree that HTTP status codes should be for transport
>rather than application errors.
+1
From: Ron Wilson <ronw.m...@gmail.com>
To: fossil-users@lists.fossil-scm.org
Sent: Friday, September 9, 2011 10:11 AM
Subject: Re: [fossil-users] Draft
On Fri, Sep 9, 2011 at 2:46 PM, Martin S. Weber wrote:
> ... and c) a separation of concerns (you, fossil library, take care of
> the fossil stuff, I take care of invoking hooks, presenting ...
I think that invoking hooks would be an intermediary between the
client and a "pure Fossil" server. Kee
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 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)
>>>
>
On Fri, Sep 9, 2011 at 7:38 AM, Martin S. Weber 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.
> preference of us
On Thu, Sep 8, 2011 at 10:27 PM, Stephan Beal wrote:
> i recommend JSON mainly for portability. It can be generated (with some
> limitations) even from shell scripts and posted via wget or curl.
> Form-encoding is more expensive and (with JSON) unnecessary. That said, i
> have code in place (in a
On Thu, Sep 8, 2011 at 11:05 PM, Jos Groot Lipman wrote:
> **
> A well designed JSON-interface would certainly have made my experiment
> easier.
>
Then keep the ideas coming :).
>
> One thought: when the interface would rely on GET/POST it might create
> cross-
>
domain problems when used from
A JSON/REST interface sounds very promising.
A few weeks ago I was playing around and tried creating a client-side
file-browser treeview in HTML.
What I ended up doing was getting the raw artifact (/raw/) and parsing it
clientside. Not exactly perfect so I dropped it.
A well designed JSON-inter
On Thu, Sep 8, 2011 at 10:27 PM, Stephan Beal wrote:
> week about that, actually, and we discussed a few implementation
> differences.) The current code (called cson) is Public Domain, so there's no
> licensing constraint. See: http://whiki.wanderinghorse.net/wikis/cson/
>
Actually... the underl
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)
>>
>
> I couldn't agree more. One of my goals (luckily no milestone I'll ever be
> evaluated against) i
On 09/08/11 16:01, Stephan Beal wrote:
Hi, all!
Management Summary: if you are _at all_ interested in seeing a JSON
REST-style interface added to fossil, please continue reading. If not,
don't bother!
Since you've read this far, we'll go ahead and continue...
Earlier this week i was awarded th
Hi, all!
Management Summary: if you are _at all_ interested in seeing a JSON
REST-style interface added to fossil, please continue reading. If not, don't
bother!
Since you've read this far, we'll go ahead and continue...
Earlier this week i was awarded the great pleasure of sitting down with DRH
24 matches
Mail list logo
