[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "notify" file

From: Laird Nelson
Subject: Re: "notify" file
Date: Wed, 06 Dec 2000 16:40:50 -0500

"Derek R. Price" wrote:
> There have been a few discussions lately about this kind of thing as
> well, including one that suggested always providing all available
> information for a hook in environment variables, similar to CGI, but I'm
> not sure now that this patch isn't a better solution since it should be
> harder to accidentally fill up a child's environment memory since an
> administrator could pare the args going to a script when they _didn't_
> want all the data.  Of course, maybe some sort of pipe to squirt all the
> data through as XML would be even better than that but I'm not sure I
> understand all the issues here.

How about take a chapter out of the CGI/web book and shove all
parameters in url-encoded form on STDIN?  Then people can use existing
code libraries/snippets to parse this string into name/value pairs. 
Just like an HTTP POST form submission.  Then you don't have to remember
which 2037 arguments to add to the script invocation in the *info file,
and the script's environment isn't filled up unless the script wants it
to be.

So here's an example (the following would show up on stdin of the
commitinfo program, let's say):


Running this through a standard URL unescaper (perl -MCGI -e 'print


...and running this through a standard webbish/libwww slicer and dicer
program you'd get (the following is my own syntax):

filespec=a|1.2|1.3|OLD_TAG, b|1.1|1.2|OLD_TAG

Or you could make the filespec syntax resemble the Entries file, if you
wanted.  I've chosen <filename>|<oldversion>|<newversion>|<stickytag>


W: address@hidden / P: address@hidden
Good, cheap, fast: pick two.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]