| Subject: | Possible issue with SOAP::Serializer |
Hi,
I was carefully reading over the Serializer POD docs, and I stumbled onto the "REGISTERING A NEW DATA TYPE" section, it's located here:
http://search.cpan.org/~phred/SOAP-Lite-1.19/lib/SOAP/Serializer.pod#REGISTERING_A_NEW_DATA_TYPE
I think either the docs here overstate the abilities of the code, or there is a bug.
Specifically, following the directions here *will* create a new type callback, however it will never be invoked, as the existence of a callback (even with proper precedence) is not sufficient to push that callback into the type handler chain. In order to do that there is an additional step, which is to create an entry within the _typelookup_order array.
Basically the method encode_scalar() iterates over the _typelookup_order array, which is purportedly populated via the very first call to the method typelookup, but not via direct manipulation of the type callback registry hash. In order for your new callback to be invoked you must actually add an entry to this array, otherwise it's existence is not considered.
There are probably a few ways to fix this, but my initial thought is that ditching the typeorder array is the way to go - probably replacing it with some type of lazyloader that generates a cached array which can autoupdate if it's invalidated. It's not clear to me what direction you'd want to go though, but I'm willing to help here with patches after discussion.
While here I also noticed that the documentation did not specify the collation of the precedence value associated with the registration of a type callback. I personally assumed that higher was better, which actually ended up not being the case. The lower the precedence value, the sooner your callback will be within the chain. I find it incredibly unlikely that anyone is using this feature, but it's possibly worth adding to the docs for completeness purposes.
The reason I was even looking at this is probably of interest. XMLRPC::Lite inherits these methods, which I use as part of an API I maintain. I've noticed the UTF8 handling within XMLRPC::Lite leaves much to be desired. Basically any utf8 characters are base64 encoded, which is a pretty weird thing to be doing. What I've done is register a u_string handler using this facility, which ultimately results in the normally expected xmlrpc document, which thus far seems to be the better way to go. I'd be happy to share that idiom if you're interested, as I've seen many questions regarding this on various forums.
thanks very much for your work here
-Kevin