Hi, all,
Now that i've got my head around th1 and what it can/can't do, i'd like to
move on to implementing custom commands, as opposed to custom pages (which
take more time to develop/test than CLI code, in my experience, and will be
much easier once the infrastructure for CLI mode is out of the way).
Part 1: Custom command storage (where do we put them?)
We have several options for how we can store custom scripts:
1) In a new db table.
2) In the filesystem as versioned files, analog to the versioned properties.
3) In the filesystem but not necessarily tracked by fossil (in this case,
the "custom" command would look for files matching the command name and
some common suffix).
Question #1: What storage mechanism(s) do we want?
My current gut feeling is to use approach #2 because it participates in
both versioning and syncing. Since nobody can force a user to run a custom
command, i "don't think that" synchronizing such scripts this way
introduces a security risk. (Unless, that is, we eventually add the ability
to run custom commands as trigger handlers.)
That said, we could probably support all 3, trying each one in some
specified order.
To avoid having tons of copy/pasted scripts, we'll also need a mechanism
which allows th1 to load external scripts (e.g. the user's standard library
of helper routines), e.g. an "include" command in TH1, but the source of
the data to feed the include command largely depends on what storage we use
for the custom commands, since users would presumably expect "include" to
pull from the same source (and i can't see a reason to split those into a
separate storage space).
Part 2: the CLI interface
The CLI command, as i [currently] envision it, would look something like:
fossil [fossil flags] custom [command flags] -- [args passed to the
script, ignored by Fossil]
The "--" marker is the conventional "end of args" flag, used by several
tools to indicate that what comes after it should be ignored by the app
and/or passed on to a subordinate process.
In support of that i would change the current args processing to stop if it
sees a -- in the arguments, and put any arguments after -- in a new array
which would only(?) be used in script code. (We might find other uses for
it.) (Trivia: fossil's internal argument handling does not directly allow
us to know _where_ an argument is in the argument list, which is why
scripts need a separate "argument space" for themselves.)
Usage would look something like:
fossil custom list-users
fossil custom my-timeline -- user=drh limit=5
fossil -R myrepo.fsl custom last-5-ticket-changes
etc.
Question #2: Does such a CLI usage agree with everyone, or is there a major
flaw with this (or a better way to do it)?
i'm very hesitant to provide anything more than read access to the db via
scripts, e.g. no custom user administration command, as the potential for
disaster/data loss is just too great. If we decide to add specific write
features (e.g. scripting the append of a wiki page comment), those should
(if really needed) be added as individual scripting APIs as opposed to via
SQL-level operations. e.g. (wikipage PageName append "....").
Whatever storage option(s) we use, fossil would look in some designated
place for the given command (filesystem or db, as appropriate), import it,
and run it through the TH1 interpreter.
Once the CLI mode is in place, it "should" translate fairly well over to
HTTP mode, but that mode introduces other questions like which page layout
template to use (how to implement such templates), its mime type, etc. i've
been prototyping some layout stuff, but have not been happy with any of it
so far, so the search continues.
PS: is "custom" the right name for this feature? Nothing else suitable
comes to mind, but i'm famously narrow-sighted at times.
Happy Hacking!
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
