On Tue, Jul 23, 2013 at 3:25 AM, Aaron W.Hsu <arcf...@sacrideo.us> wrote:
> I’ve so far managed to avoid using the feature myself, but I have been on > teams where people tried to use this to some effect, and unfortunately, the > interfaces always seemed to scale very poorly. That’s not to say that they > cannot be made to scale, but it seems to be a little too fragile for my > sensibilities. Monotone’s integrated scripting, on the other hand, had > another problem. From an user’s perspective, I found that the strict > support for a single scripting language made it difficult to integrate > Monotone fully into whatever project I was using. > Hi Aaron, you've just summarized two of the hurdles any potential scripting language would have vis-a-vis v2. My current thinking is that if the library's interface is sane then we can bind it to arbitrary script languages and find out which one is best. i've got lots of experience with binding third-party libraries to scripting engines (SpiderMonkey, Google v8, QtScript, TH1, and custom engines) and have a fairly good feel for what is required of a C API vis-a-vis scripting engines. So i'm fairly confident that, with the help of the list, we can conquer this without all that much grief. It'll be fun :). > While the Lua scripting enabled me to gain a level of sophistication and > relative rigor in the process more than what I could get from normal UNIX > plumbing, if my project wasn’t in Lua in the first place, I found it > breaking my concentration a good deal more than I would have liked. > That's my impression of lua, though i haven't worked with it (it's too weird, both at the script and C API level). > I feel like there should be a balance when it comes to extensibility. > Indeed, I think that a good DVCS ought to never require the user to start > extending or programming their VCS in order to use it normally from day to > day. > And we shall call it "fossilmacs" :) > The plug-and-play nature of Fossil is a huge advantage to me right now, as > it’s so simple to use and get running on any given platform and workflow. > It just works, and does not rely on any extension interface, such as a > scripting or hook layer to get things done. > One of my goals is that we will be able to compile specific modules in and out, e.g. the HTML UI might not be needed for someone who just wants an AJAX back-end. Ideally these could be compiled in/out or be loaded at runtime, but runtime loading is a low priority [for me] because static binaries of fossil are amazingly popular. On the other hand, it seems to me that scripting and a programmatic > interface *is* very good when it comes to integrating VCS into a project’s > workflow. > In my experience scripting is the only flexible way to do this. Once an API is scriptable, all kinds of new/unimagined things become possible with it. > It’s this last part that I think should be the target of any > extensibility. I would argue that, to me, one should not direct the > programmatic interface towards end-users, but rather, those who wish to > integrate Fossil into a larger framework. > That's a good point. > In that case, I see the limitation of a single scripting language as a > problem. I also think that the ad hoc nature of a “text” based interface > like UNIX style plumbing to be a problem. Instead, perhaps there is a way > of creating a public interface to Fossil that allows one to reliably extend > its functionality without restricting yourself to a single language. > That's one of my primary goals. i recently developed my own scripting engine and will be developing a fossil wrapper in that language parallel to any v2 development, the intention being to make sure that the v2 interface is indeed suitable for scripting. Here’s a simple idea of how this might work. Publish a specific interface > in C against which people can write their code. Allow people to generate > shared objects that export a specific set of functions for registering or > extending functionality of the Fossil executable. > That's in principal where i'd like to head. i'd like for modules to be either statically or dynamically linkable, but those details are still far down the road and does not affect the planning of the overall architecture at this point. > Then, these executables can be placed inside of a specific directory, > perhaps found through a set of paths in an environment variable. > i'm also thinking something like: export FOSSIL_AUTOLOAD_MODULES=foo,bar,baz and it would try to load those from $FOSSIL_MODULES_PATH. When fossil runs, it can dynamically link in any of the shared objects that > it finds there, and these can register additional functionality with the > Fossil system. > And we're very much on the same page. Note, however, that people really like having fossil as a static binary, so that will likely be the "tier 1 target." > In this way, people can use whatever language they want to use, as long as > it has a bi-directional C FFI, which most languages I have seen have. The > fossil executable will still be shipped as a single executable, and people > would only need a simple C header file to use the extended features, which > can be obtained separately. It would have the benefit of a rigorously > defined interface with more than textual interfaces for increased > reliability of the code, but people could still use shell scripts if that’s > what they really wanted to do, they would just have to be dispatched from a > shared object. > > Just a few thoughts that I have wondered about when it comes to extension > interfaces. Most of the time I tend not to use them because they don’t work > with my language or they are too ad hoc for me to rely on. I think the > above would solve those issues while still keeping Fossil dirt simple for > the end user. > By all means, feel free to propose concrete interfaces. At this point v2 is "just talk" - there is no code, no concrete plan. i have lots of things i would like to try out, in terms of finding the "shape" of the library without actually writing implementation code, and that's where i'll be spending much of the next few days (in between dog walks), and will post a link once i've got some headers sketched out. -- ----- 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
