perl (was Re: Introduction)

[Greg Hudson <gh...@MIT.EDU>]

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.

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.

Second, server triggers.  We have a high-commitment option with regard
to server triggers, which is linking the perl interpreter into the
server as a compile-time option, and making perl code a form of server
trigger.  If and when it comes time to decide whether to do this, I'd
consider the following as axioms:

	* Server triggers are usually not very complicated, at least
	  if Subversion has done a good job providing the
	  fundamentals.  (CVS does not, and I've seen some rather
	  complicate perl trigger scripts as a result.)

	* Regardless of what developers think, perl is a really really
	  big favorite among Unix system administrators.

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.

For the record, I despise perl as a development language and agree
with all the bad things people have said about it here, although I do
use it from time to time.  But I won't go into detail.

Triggers (was: Re: perl (was Re: Introduction))

[Greg Stein <gs...@lyra.org>]

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/