On Apr 3, 2017, at 1:29 AM, Stephan Beal <sgb...@googlemail.com> wrote:
>
> Commits can't be done without a checkout
Given a way to ask Fossil over HTTP for the set of artifacts that makes up
$reference, where the latter is anything Fossil currently accepts in “fossil up
$reference” you’ll then have a way to check out that version:
$ frapi checkout https://m...@fossil-scm.org
Password, remember, etc.
…fossil-scm/ created and populated with tip-of-trunk
$ cd fossil-scm
…hack, hack, hack…
$ frapi ci
…diff checkout against pristine copies, send diffs up to server
This hypothetical lightweight client (which I’m calling frapi) would then
record the version it checked out, so that on checkin, it can run the diffs
against the pristine copies it squirreled away (like Subversion does) and
submit the diffs to the backend to be checked in or rejected.
On success, it gets back a new checkin ID, which it records in the same place
it recorded the initial checkin ID, ready to go again.
I think a local JSON file would make sense for that place, again a lightweight
alternative to .fslckout and ~/.fossil. This client already has to have a JSON
parser built in, but does *not* have a reason for an embedded SQLite DB.
The use case that prompted all of this — and it is admittedly silly — is
thinking about what it would take to port Fossil to a PDP-11. Whether anyone
actually does that is not the point. The point is that such constraints should
guide the design of this lightweight client.
Such a client would necessarily be different from the current Fossil
implementation. We must get something new and different out of it, else why
bother?
Incidentally, I don’t mean with all of this to disrespect Fossil itself. I’m
not proposing replacing it because it’s bad. I’m just proposing a…shuttle
craft, for use when we can’t fly the Enterprise itself on the mission. The
shuttlecraft always comes back home, and we can’t always use them, as when
Ubering around Lwaxana Troi. Gotta use the whole Enterprise for such things,
you know. :)
> Fetching binary blobs directly with JSON
While that might be useful, I’m proposing that there be a way to get artifact
data raw, directly over HTTP, just like downloading a file.
This is what I meant by JSON only being a default, when no better
representation exists. For “frapi up $version” and such, that better
representation is “raw.” Content-Length, binary data, the whole bit.
I suppose it could optionally be delta-compressed against the version the
client claims to have, to save bandwidth.
> (my preferred solution) the JSON sends back links which, when visited, return
> the raw blobs.
While that sounds like a useful API, a two round-trip solution introduces the
possibility of race conditions.
For “frapi up”, you’d want a way to say “I have version $uuid, give me the tip
of that artifact’s branch, optionally delta-compressed.”
This is also what I meant by this REST API being its own thing, designed with
stateless HTTP in mind: you give everything in the request that tells the
server what it needs to know to process your entire request in one go.
Ideally, every operation takes only one round-trip. The server carries the
bulk of the processing workload.
That not only avoids race conditions, it means you pay for only one HTTP
round-trip delay.
> i was going by past experience with at-work projects, where my colleagues are
> sticklers for differentiating between PUT/POST (insert vs. update).
Yes, all experienced web devs know exactly how it should be done…and no one
agrees. :)
It’s spaces vs tabs and emacs vs vi all over again.
The point here, though, is that doing everything with GET and POST is entirely
doable and legal within the REST concept.
> CGI accounts for 100% of my fossil access :). (That was the killer feature
> for me when i very first looked at fossil.)
I’m not suggesting that we change anything that already exists. I’m just
saying that if, for some reason, the person implementing this decided that they
absolutely positively had to use the PUT verb for one new API that only frapi
used, that would be fine by me.
> 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.
$5 gets you a root access VPS these days, plenty big enough to run Fossil.
Shop around.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
