Re: [xslt] plugin patch v3 plus exslt:regexp implementation

[Daniel Veillard <veillard redhat com>]

On Sat, Jan 08, 2005 at 07:22:04PM -0500, Joel Reed wrote:
> I've attached a new version of the plugin patch, plus an
> implementation of exslt:regexp.
> 
> The plugin implements exslt:replace, exslt:match, and exslt:test
> as documented here: http://www.exslt.org/regexp/index.html
> The plugin uses pcre 5.0 or later. It was tested against libxml2 CVS
> and libxslt CVS plus plugin patch.
> 
> I built some test cases and ran the code thru many permutations
> all successful, but this is the first time i've coded xpath return 
> sets and used pcre, so code reviews/testing help appreciated.
> 
> The xslt plugin patch has been updated to the new libxml2 module
> api, plus it now actually calls xmlModuleClose in xsltCleanupGlobals.
> 
> I plan to check out and try to add hooks to xslt security module,
> and eventually test on win32. Please feel free to beat me to win32
> if you like :-)

  Joel and I had a little chat on IRC, about some things to fix or
improve about the patch, but I expect to commit it later today in CVS
after a bit of cleanup:

<DV> xsltExtModuleRegisterDynamic : you can't define it as a function or as a macro depending on the context
<jreed> ok, for ABI?
<DV> this sounds fishy to me. Returning -1 if not defined is IMHO a lot cleaner
<DV> ABI and API
<jreed> ok
<DV> rc = xmlModuleSymbol(m, "exsltRegisterModule", (void**)&regfunc);
<DV> if that fail, shouldn't you unload it ?
<jreed> good pt
<DV> also if multiple modules export exsltRegisterModule() entry points wouldn't that clash on some arches ?
<DV> also the way to compute the modulename based on the URI should be documenbted in the function header
<DV> as well as the global variables associated, remember we have little docs
<jreed> it didn't seem to clash when i tested, but thats what i thought too
<DV> and the simplest is to extract from the code: -)
<DV> "no clash", good but is that Linux specific ?
<DV> maybe I should post a follow-up on the list instead :-)
<jreed> i started looking at other plugin collections, and saw sometimes diff names, sometimes all the same entry pts
<jreed> names
<DV> okay, I know python does something like this but use the module name in the looked up function
<jreed> right, i saw that occasionally
<DV> void initlibxml2mod(void); for "import libxml2"
<DV> void initlibxsltmod(void); for "import libxslt"
<DV> this sounds safer to me, honnestly
<jreed> at the time, i dismissed it because i was still thinking of libexslt as modules, but now that i'm not going that way, could use module name in initfunc
<jreed> ok
* DV ponder posting the IRC logs on the list for more global and archived communications
<jreed> ok, well i copied your notes onto my TODO list at least
<DV> I wonder if I should apply and commit or you make another patch 
<DV> what do you perfer ?
<DV> prefer
<jreed> easier applied, but which u like. 
<DV> and what am I supposed to do with xslt-plugin-regexp-0.1.tar.gz ? 
<jreed> i _was_ wondering how plugins would be distributed
<DV> Okay I wll apply but then patches will need to be made against CVS
<jreed> maybe a plugin subdir or contrib subdir?
<DV> on xmlsoft.org? 
<jreed> i really had no idea
<DV> I'm a little vary of making a registry
<DV> let me explain a bit:
<DV> you build the module name from the URI provided
<DV> it's a reduction operation, multiple URI may clash resulting in the same module name
<DV> I tend to dislike that because URI were used precisely because it's a way to avoid a registry for names
<jreed> right, because i wanted to prevent any directory type ops for security
<jreed> ok
<DV> okay but keeping a bijective name transform you be cleaner
<jreed> how about full url with s/\//_/g or something?
<jreed> i'm noticing underbars come out as nothing on irc
<DV> and would not lead to troubles for example if someone else decides to define another regexp module
<DV> _ show fine for me, the transformation would be okay
<jreed> ok
<jreed> will change
<DV> I think java does soemthing like removing the http:// (or protocol prefix) and then s+/+\.+g
<DV> the scheme sounds fine to me
<jreed> ok
<DV> ideally isolate this transformation as a separate function
<DV> I would also remove the trailing / if any
<jreed> ok
<DV> and replace \ with _
<DV> well once isolated fine-tuning sounds simple to hack
<jreed> yes
<jreed> well, thanks for feedback, will post new patch when fxd
<DV> if we do that I'm fine with a pluging repository, because "blessed" packages won't conflict with not registered ones
* DV think this is exciting because it is architecture work :-)
<jreed> ok, sounds good
<jreed> hehe
<DV> ftp://xmlsoft.org/plugins http://xmlsoft.org/download/plugins
<jreed> i like it, because it makes things easier for contributors
<jreed> hopefully
<DV> I will also reformat your code with my cb script:
<DV> paphio:~/XML -> cat ~/bin/cb
<DV> #!/bin/sh
<DV> indent -bad -bap -bbb -bli4 -br -ce -brs -cs -i4 -l75 -lc75 -nut -sbi4 -psl -saf -sai -saw -sbi4 -ss -sc -cdw -cli4 -npcs -nbc
<DV> paphio:~/XML ->
<DV> for consistency of libxslt code (but not the plugin)
<jreed> ok


Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/