I am a relatively new Fossil user, and I have not even really stretched
fossil’s muscles yet. However, I have made extensive use of Git and Monotone. I
far preferred Monotone to Git, but the social pressures eventually made me give
up fighting for Monotone and move to Git. I hope that Fossil can provide a
number of the things that I really enjoyed about Monotone without the
associated disadvantages.
This brings me to the discussion that I have seen about Scripting languages in
DVCS systems. I’m really not sure how I feel about scripting and all of these
hooks in various DVCS systems, especially in comparison to the relative plug
and play nature of Fossil. In particular, I am thinking of the very plumbing
oriented nature of Git, and the very integrated scripting layer, in Lua, for
Monotone. For one thing, while I enjoy the dirty convenience of the piping and
UNIX style workflow for most work, I’m not as convinced when it comes to
version control.
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. 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.
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. 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. 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. 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. 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.
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. Then, these executables can be placed
inside of a specific directory, perhaps found through a set of paths in an
environment variable. 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. 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.
--
Aaron W. Hsu | arcf...@sacrideo.us | http://www.sacrideo.us
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
