Re: Dropping mod_sed into /trunk/ ?
Hi, There is one important aspect of mod_sed design (which is borrowed from Sun Web Server) that I would like to emphasize is that sed code has been separated from filter code. So sed code itself can be archived in a shared/static library (let me call it as libsed). mod_sed filter code is just one consumer of libsed. Typical usage of libsed is : sed_commands_t cmd sed_init_commands(cmd, ...); sed_compile_string(cmd, string1); sed_compile_string(cmd, string2); sed_finalize_command(cmd); // Run eval on compiled context any number times. sed_eval_t eval; sed_init_eval(eval, ...); sed_eval_buffer(eval, ...); sed_finalize_eval(eval, ...); // finally destroy the evaluation and compile context sed_destroy_eval(eval); sed_destroy_commands(cmd); Having said that, I would like to emphasize the sed command and evaluation context doesn't store any thread local storage. What this means is that multiple commands and evalution context can be created within a single thread. This means multiple consumers of libsed can be consumed safely in a single thread. This way, any number of apache modules can make use of sed libraries and coexist in a same thread. If developers like this idea then one option is to drop libsed code into apr and drop mod_sed.c (which is a sed filter module) into apache code. libsed code lies in sed0.c sed1.c and regexp.c regexp.h libsed.h Whereas filter code is in mod_sed.c http://src.opensolaris.org/source/xref/webstack/mod_sed/ Regards, Basant. On Wed, Aug 20, 2008 at 11:53:58PM +0100, Nick Kew wrote: A little while ago, Basant Kukreja published mod_sed under the Apache license. He's now also written a blog entry that could become the basis for a tutorial into how mod_sed is much more than a mere string-or-regexp search-and-replace filter: http://blogs.sun.com/basant/entry/using_mod_sed_to_filter I happen to know that Basant and Sun will be happy for us to adopt mod_sed, and I think that with that blog entry reworked into a howto doc, it'll add real value to httpd. Any thoughts on dropping it in to trunk, with a view to including it as standard in 2.4 in due course? -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: Dropping mod_sed into /trunk/ ?
I have a request, in mod_sed, if there are multiline commands, specifying them is cumbersome, It would be nice to have the ability to specify a script file instead. |There is one important aspect of mod_sed design (which is borrowed from Sun | Web Server) that I would like to emphasize is that sed code has been separated | from filter code. So sed code itself can be archived in a shared/static library | (let me call it as libsed). mod_sed filter code is just one consumer of libsed. rahul -- 1. e4 _
Re: Dropping mod_sed into /trunk/ ?
On Sat, Aug 23, 2008 at 05:28:05PM +0530, rahul wrote: I have a request, in mod_sed, if there are multiline commands, specifying them is cumbersome, It would be nice to have the ability to specify a script file instead. I agree. But I think mod_sed should support both. Any votes or comments? E.g OutputSedScriptFile and InputSedScriptFile can read the sed commands from sed script file. libsed has a function to process file based request. It is matter of adding few lines of code (additional configuration) in mod_sed to include this capability. Regards, Basant.
Re: Dropping mod_sed into /trunk/ ?
On Wed, Aug 20, 2008 at 6:53 PM, Nick Kew [EMAIL PROTECTED] wrote: Any thoughts on dropping it in to trunk Is it best to preserve the current files/filenames (sed.h, libsed.h, sed0.c, etc.) to better reflect the history of that code, or should the files be combined/renamed to something that makes more sense for an Apache module that shares space with a lot of other modules? (I'm assuming this goes into modules/filters and not its own modules/sed.)
Re: Dropping mod_sed into /trunk/ ?
On Thu, Aug 21, 2008 at 1:53 PM, Jeff Trawick [EMAIL PROTECTED] wrote: On Wed, Aug 20, 2008 at 6:53 PM, Nick Kew [EMAIL PROTECTED] wrote: Any thoughts on dropping it in to trunk Is it best to preserve the current files/filenames (sed.h, libsed.h, sed0.c, etc.) to better reflect the history of that code, or should the files be combined/renamed to something that makes more sense for an Apache module that shares space with a lot of other modules? (I'm assuming this goes into modules/filters and not its own modules/sed.) Renaming them to fit better in for the apache file tree seems a good idea. If its not done it will probably get done at some point in the future anyway. ~Jorge
Re: Dropping mod_sed into /trunk/ ?
| Any thoughts on dropping it in to trunk, with a view | to including it as standard in 2.4 in due course? | | mod_sed is much more than a mere string-or-regexp search-and-replace What happens to mod_substitute? especially since what substitute provides seems to be a strict subset of mod_sed ? rahul -- 1. e4 _
Re: Dropping mod_sed into /trunk/ ?
On Aug 20, 2008, at 6:53 PM, Nick Kew wrote: A little while ago, Basant Kukreja published mod_sed under the Apache license. He's now also written a blog entry that could become the basis for a tutorial into how mod_sed is much more than a mere string-or-regexp search-and-replace filter: http://blogs.sun.com/basant/entry/using_mod_sed_to_filter I happen to know that Basant and Sun will be happy for us to adopt mod_sed, and I think that with that blog entry reworked into a howto doc, it'll add real value to httpd. Any thoughts on dropping it in to trunk, with a view to including it as standard in 2.4 in due course? We will need, of course, the IP clearance issues resolved.
Re: Dropping mod_sed into /trunk/ ?
On 21 Aug 2008, at 13:02, rahul wrote: | Any thoughts on dropping it in to trunk, with a view | to including it as standard in 2.4 in due course? | | mod_sed is much more than a mere string-or-regexp search-and- replace What happens to mod_substitute? especially since what substitute provides seems to be a strict subset of mod_sed ? That's a decision that can wait for 2.4, by which time we should have more user feedback to base it on. -- Nick Kew
Re: Dropping mod_sed into /trunk/ ?
On 21 Aug 2008, at 13:28, Jim Jagielski wrote:
On Aug 20, 2008, at 6:53 PM, Nick Kew wrote:
A little while ago, Basant Kukreja published mod_sed under the
Apache license. He's now also written a blog entry that could
become the basis for a tutorial into how mod_sed is much more
than a mere string-or-regexp search-and-replace filter:
http://blogs.sun.com/basant/entry/using_mod_sed_to_filter
I happen to know that Basant and Sun will be happy for us
to adopt mod_sed, and I think that with that blog entry
reworked into a howto doc, it'll add real value to httpd.
Any thoughts on dropping it in to trunk, with a view
to including it as standard in 2.4 in due course?
We will need, of course, the IP clearance issues resolved.
Of course we have a long-standing CCLA from Sun.
Basant, do we have an ICLA from you?
http://www.apache.org/licenses/icla.{txt|pdf}
(Technically it's sufficient that it's Apache-licensed, if we preserve
the third-party notices. But that's not really what's proposed :-)
--
Nick Kew
Re: Dropping mod_sed into /trunk/ ?
Thanks Nick for your initiative to make it part of Apache httpd. I am glad to
contribute to the Apache Software Foundation.
On Thu, Aug 21, 2008 at 02:04:14PM +0100, Nick Kew wrote:
On 21 Aug 2008, at 13:28, Jim Jagielski wrote:
On Aug 20, 2008, at 6:53 PM, Nick Kew wrote:
A little while ago, Basant Kukreja published mod_sed under the
Apache license. He's now also written a blog entry that could
become the basis for a tutorial into how mod_sed is much more
than a mere string-or-regexp search-and-replace filter:
http://blogs.sun.com/basant/entry/using_mod_sed_to_filter
I happen to know that Basant and Sun will be happy for us
to adopt mod_sed, and I think that with that blog entry
reworked into a howto doc, it'll add real value to httpd.
Any thoughts on dropping it in to trunk, with a view
to including it as standard in 2.4 in due course?
We will need, of course, the IP clearance issues resolved.
Of course we have a long-standing CCLA from Sun.
Basant, do we have an ICLA from you?
http://www.apache.org/licenses/icla.{txt|pdf}
(Technically it's sufficient that it's Apache-licensed, if we preserve
the third-party notices. But that's not really what's proposed :-)
I have not yet send the ICLA. I will send the signed document and post it in a
day or two.
--
Nick Kew
Regards,
Basant.
Dropping mod_sed into /trunk/ ?
A little while ago, Basant Kukreja published mod_sed under the Apache license. He's now also written a blog entry that could become the basis for a tutorial into how mod_sed is much more than a mere string-or-regexp search-and-replace filter: http://blogs.sun.com/basant/entry/using_mod_sed_to_filter I happen to know that Basant and Sun will be happy for us to adopt mod_sed, and I think that with that blog entry reworked into a howto doc, it'll add real value to httpd. Any thoughts on dropping it in to trunk, with a view to including it as standard in 2.4 in due course? -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: Dropping mod_sed into /trunk/ ?
Nick Kew wrote: A little while ago, Basant Kukreja published mod_sed under the Apache license. He's now also written a blog entry that could become the basis for a tutorial into how mod_sed is much more than a mere string-or-regexp search-and-replace filter: http://blogs.sun.com/basant/entry/using_mod_sed_to_filter I happen to know that Basant and Sun will be happy for us to adopt mod_sed, and I think that with that blog entry reworked into a howto doc, it'll add real value to httpd. Any thoughts on dropping it in to trunk, with a view to including it as standard in 2.4 in due course? I have no objection. mod_sed is much more than a mere string-or-regexp search-and-replace It's nice to see my objections to an earlier module name reinforced by a practical example of why only mod_sed deserves the sed designation :)
