On Fri, Aug 3, 2012 at 3:49 PM, Michal Suchanek <[email protected]> wrote:
> And how do you prevent malicious code import through synchronization? > The same way Windows does, of course: "This app comes from god-only-knows where. Do you want to run it?" ;) i have absolutely no idea, to be honest. > This is the exact same thing. Either you don't import or don't use > what you import or you are vulnerable to what you import. > The difference with custom commands, compared to what is currently syncable, is that they will have a lot more power via access to stuff which was not accessible before. e.g. a query API has been added to the scripting language (th1). One very interesting (under consideration) feature of custom commands/pages is that we could _potentially_ offer an option to direct built-in commands to a custom command. If such things are synced, then i might get your version of "fossil status" instead of mine, and that would upset me. The custom commands API currently offers nothing which will allow one to change a repo's state and there are NO plans to add such APIs, for repo integrity reasons. Even so, with greater power comes bigger cans of worms, so any synchronization must be carefully considered. Initial templates/commands support _might_ live in a new table of its own (this is still undecided) which will initially not be syncable but would eventually be made so, _probably_ via an extension of the "config" command (or something equivalent). They might live in the artifacts table (where they could be versioned and synced as normal artifacts), and whether or not to version custom pages/commands is a decision which has not yet been made (as always: opinions on the matter are welcomed). It might be interesting, and wouldn't be much work, to provide several methods for storing custom commands: config table, artifacts, and/or local files. e.g. for prototyping this support i use local files, and once i'm (eventually) satisfied with the overall model i'll figure out (hopefully with the help of the community) where best to store such things. -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
