On Tue, 23 Jul 2013 10:29:36 +0200, Stephan Beal <sgb...@googlemail.com>
wrote:
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).
really? regarding the language (the scripting level) I find lua
exceptionally well thought out and clear. the syntax is
intentionally very "boring" -- no surprises here -- and sure much easier
to swallow than tcl, for instance, for people
starting from scratch. regarding the C level API I don't have any
experience (nor an opinion)
but it claims to be much easier than that of other scripting languages.
the LaTeX guys at least have decided to
move into this direction to get a real scripting facility into latex
http://luatex.org/ which personally
I feel was a good decision.
which is not to mean that I want to advertise lua here. ultimately I
personally don't care too much
and, as has been said in this thread elsewhere already I would argue that
for 99.9% of the projects of 99.9% of the users
there should be (and probably actually will be) no need to script a
revision control system (beyond, maybe, some basic shell script drivers
patching together fossil commands): the SCM needs to provide the required
functionality through it's commmand set.
I also do hope any potential changes/extensions will not interfere with
the current 'look and feel' of fossil (the
single-executable/zero-installation-overhead, minimal dependencies, and
single file for whole
repo (and, yes, the nice web ui, although personally I could live without
it) are the things which sets fossil apart.
otherwise I would just use mercurial ;-).
personally, my impression is that the absence of a scripting facility is
_not_ high on the least of current shortcomings. maybe, one should
try to also go through the archives and the assorted wish lists and to
agree among the developers which functionality changes should be
implemented if the serious overhaul to realize `fossil2' (please don't
call it that in the end...) is actually undertaken. `grep' sure would be
high on my list as would be a more consistent and less idiosyncratic CLI.
E.g., I'm very happy that recently significant progress has been achieved
regarding the use of SSH (long overdue, I feel) which I find more
important than any scripting facilities in one or more languages.
but maybe my perspective is to limited ;-)
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.
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
