[jira] Kommentiert: (XMLRPC-75) Introspection Patch for XML-RPC, current to SVN 2005-12-29 (r359943)

["Jochen Wiedmann (JIRA)" <xm...@ws.apache.org>]

    [ http://issues.apache.org/jira/browse/XMLRPC-75?page=comments#action_12368808 ] 

Jochen Wiedmann commented on XMLRPC-75:
---------------------------------------

Walter, I have committed some changes, that make AbstractReflectiveXmlRpcHandlerMapping implement the XmlRpcMetaDataHandlerMapping interface. Please, note the following:

- The implementation ensures, that the various "system.*" methods return
  consistent result. In particular, a method returned by "system.listMethods"
  is always able to provide a meaningful result for "system.methodSignature"
  and "system.methodHelp".
- I did not implement overloading. My goal is to keep the base classes simple
  and clean. I am still open for subclasses, which allow overloading.
- The code is not checked. It is quite likely, that you'll find bugs.
- Keep documentation in mind. If you need a pointer to the apt format, see
  http://maven.apache.org/guides/mini/guide-apt-format.html


> Introspection Patch for XML-RPC, current to SVN 2005-12-29 (r359943)
> --------------------------------------------------------------------
>
>          Key: XMLRPC-75
>          URL: http://issues.apache.org/jira/browse/XMLRPC-75
>      Project: XML-RPC
>         Type: New Feature
>   Components: Source
>     Versions: unspecified
>     Reporter: Walter Mundt
>     Assignee: Jochen Wiedmann
>  Attachments: IntrospectionExample.java, xmlrpc-2.0-beta-introspection.patch, xmlrpc3-metadata.diff, xmlrpc3-metadata.diff, xmlrpc3-metadata.diff, xmlrpc3-metadata.diff, xmlrpc3-metadata.diff
>
> I've taken Aaron Hamid's Introspection patch (which was in turn derived from the one here: http://xmlrpc-c.sourceforge.net/hacks/helma-xmlrpc-introspection.diff ) and basically rewritten it to work with the current XML-RPC library.
> I tried to set it up so that it followed the existing coding style as much as possible, and would not break any existing applications.  For example, when I needed a list of handlers supported by a particular mapping, I added a new interface XmlRpcListableHandlerMapping that provides this information, made the default handler implement it, and designed my code so that if it were not implemented by a handler in use, everything  would work except the system.listMethods functionality that relies on it.
> I hope you will be able to integrate this code into the next version of the library; please contact me with any questions or issues.  I will be attaching the patch to this issue if I can so that the problem with his previous patch will not occur.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: [jira] Kommentiert: (XMLRPC-75) Introspection Patch for XML-RPC, current to SVN 2005-12-29 (r359943)

[Walter Mundt <Wa...@coleengineering.com>]

> 
> Walter, I have committed some changes, that make AbstractReflectiveXmlRpcHandlerMapping implement the XmlRpcMetaDataHandlerMapping interface. Please, note the following:
> 
> - The implementation ensures, that the various "system.*" methods return
>   consistent result. In particular, a method returned by "system.listMethods"
>   is always able to provide a meaningful result for "system.methodSignature"
>   and "system.methodHelp".

I don't think this is the right approach.  My preference would be to 
provide as much information through the interface as possible.  I don't 
think it inconsistent to list methods for which signatures are 
unavailable: better to say "it's there, and that's all the information I 
can provide" then to hide methods which do not support the metadata 
interfaces.

> - I did not implement overloading. My goal is to keep the base classes simple
>   and clean. I am still open for subclasses, which allow overloading.
I still disagree with this approach.  Overloading is a basic feature 
that _is_ quite simple, and requiring the addition of a subclass to 
implement it results in a poor design where other parts of the code 
unrelated to overloading also have to be reimplemented.

I'll work on a way to abstract it out without compromising on the 
cleanliness of the architecture, but in my not-so-humble opinion this 
extra effort is unreasonable because I don't see why anyone would NOT 
want overloading support.  It can't do any harm, and it me it seems 
unintuitive to map classes with overloaded methods to an RPC interface 
by just picking one of them and using that, _especially_ when the RPC 
interface itself supports overloading.

I'm sorry to be bringing this argument about overloading into the 
mostly-unrelated context of metadata support, but I'm just completely 
failing to understand the reasoning that justifies removing what I see 
as an important and fairly basic feature of the library.  Upgrades are 
supposed to enhance functionality, not remove it.

> - The code is not checked. It is quite likely, that you'll find bugs.
I'll look through it when I get some time.

> - Keep documentation in mind. If you need a pointer to the apt format, see
>   http://maven.apache.org/guides/mini/guide-apt-format.html
I will look at that later.