On Sun, Apr 2, 2017 at 11:38 PM, Warren Young <war...@etr-usa.com> wrote:
> On Apr 2, 2017, at 2:48 PM, Stephan Beal <sgb...@googlemail.com> wrote: > > > > a) that's essentially what the JSON API is > > …minus the lightweight Subversion-like client, of course. > > But, it’s good to know that most of the work is already done. > A good deal of it is. There are certainly a few holes in the API. > > with the notable exception of missing blob support (since JSON has no > definition for blobs). > > When I said that the default return representation should be JSON, I did > not mean that all data must be in JSON format. I just mean that, when no > better representation exists, the API should use JSON. > i meant more for pushing new data, e.g. commits. Commits can't be done without a checkout, though (not without significant changes, anyway). Fetching binary blobs directly with JSON can't be done without an intermediary format (base64 or whatever) or (my preferred solution) the JSON sends back links which, when visited, return the raw blobs. That would be one solution for such cases as downloads, as you mention here: > Contrast the Fossil HTTP API here, where sometimes pulling a specific file > shows it in the browser as-is, sometimes it displays it inline with other > material, and sometimes it downloads it. > With this REST API, I’d expect to get a file download every time, because > the server cannot make any assumptions about the nature of the client, > particularly about the display semantics. Web applications like Fossil UI > often make such assumptions. The REST API would be more policy-free, in > this sense. > Agreed. The current JSON API makes no assumptions about how the data will be consumed/rendered. > A strictly-REST-compliant API > > Who specifies “strict” REST? > All I see are a bunch of cliques and camps, no actual standards. > Good point. AFAIK there is no official definition (or even RFC). i was going by past experience with at-work projects, where my colleagues are sticklers for differentiating between PUT/POST (insert vs. update). That said, if some of this didn’t work with CGI, I don’t see a problem with > that, since it is merely one alternative way to access Fossil, not the main > one. CGI accounts for 100% of my fossil access :). (That was the killer feature for me when i very first looked at fossil.) > If the requirement is that you use “fossil server” with this, that seems > fine to me. > But that immediately excludes everyone who doesn't have their own root server (or otherwise has access to run server processes full-time). The majority (i suspect) of us have $5/month hosters which support PHP and CGI, but have no way to run servers jobs full-time. (Apologies for my brevity - my left hand is offline again.) -- ----- stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
