On Sun, Mar 23, 2014 at 1:17 AM, <ma...@include-once.org> wrote: > To get more out of this it might ultimatively make sense to introduce > a "/script" > page (like /header /footer and /style) for the fossil cgi/server. > Otherwise it could > get difficult (and traffic-wastey) to maintain more complex > client-side scripting. >
Hi, Mario, about 18 months ago i experimented extensively with a /scripts-like page, with the idea being that clients could create their own custom pages on the server. The main limitation turned out to be th1 - it's way too limited for anything more than a few lines of script (e.g. it cannot report error locations). Adding a /script page to serve JS is also something to think about. > It looks easy enough to add that, even introducing a few more Th_Store() > variables (something like a `$_GET(name)` array for query string params). Allowing some TH1 or TCL magic in /script could open the possibility to send > custom +json responses from there even. (The JSON RPCs are already > quite neat by themselves of course!) > in libfossil i've been experimenting with a different scripting engine (conceptually derived from th1, but actually nothing like th1 at all) and script-side JSON generation (with no need for JSON support at the C level :). It's possible that libfossil may already be able to do some of what you are trying to do. Here's a demo: http://fossil.wanderinghorse.net/repos/libfossil/cgidemo/index.cgi/ (That whole demo site is implementing in script code on top of libfossil.) -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "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
