On Fri, Mar 02, 2001 at 02:59:31PM -0500, Greg Hudson wrote:
> I know Karl would dearly love this thread to die on this list, but
> really, all of what I'm going to say is very directly tied to
> Subversion, although it's all post-1.0 stuff.
Bah. He's got a "d" key :-)
> There are two issues to consider. First, language bindings. This
> isn't really a question. If Subversion becomes popular, someone will
> do language bindings in perl. We can host them in our CVS tree or
> not; it doesn't matter especially much. Very low commitment on our
> part.
Exactly.
[ I'd prefer they were in our tree. ]
> Second, server triggers. We have a high-commitment option with regard
> to server triggers,
Agreed.
> which is linking the perl interpreter into the
> server as a compile-time option, and making perl code a form of server
> trigger.
Oof. The Perl interpreter can be a bit clunky when threading is present.
Doable, certainly, but I pity da foo' who to code this :-)
Ideally, it would be best if we could spawn a program and pipe the necessary
bits over to it, then let it talk to the repository via libsvn_fs. That will
keep the server more robust, and we won't have to link big chunks into the
server.
Of course, the performance isn't ideal, so we'll just have to see.
>...
> It may be enough to just let people call out to perl scripts via the
> shell, or it may not. Aside from performance, linking perl into the
> server has the advantages that (a) getting at interesting Subversion
> values can be made more direct, via perl global variables, instead of
> having to pass them through arguments to the script, and (b) people
> can more easily keep state between trigger calls. Or so I would
> guess; I'm not actually too familiar with the perl interpreter
> interface.
(a) is very true. I don't think (b) is going to be very possible, though.
Recall that we're in a multi-process, multi-thread environment. I believe
the Perl interpreter (because of threading) is going to require a Perl
interpreter for each thread/process. IIRC, values cannot easily be shared
between interpreters (and IIRC they *can* with some heavy lifting).
IOW, I'm with Greg. Keep Perl, Python, Guile, Tcl, whatever out of our
implementation, but allow them for triggers. Possibly as spawned programs,
possibly linked directly in.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:24 2006