Re: xml-rpc messages

[Kevin Ross]

For the most part, I agree.

For example:

- xindice    
    - core // all real code not interfacing with outside protocols goes here.
         - supporting server classes
    - service
         -XPathQueryService // interface
         - xmlrpc
             - XPathQueryService // xmlrpc implementation implements top level interface, calls core classes
    - client
         - xmlrpc
             - XPathQueryServiceClient // xmlrpc implementation implements top level service interface, calls service implementation
    - util

-Kevin Ross

John Wright wrote:

What bothers me a little is that in a class placed in the client
    

package, > you
  

will have to import org.apache.xindice.SERVER.rpc.* classes.  Should a
    

client
      

_import_ server classes, that's my question?  I don't particularly
    

like this
  

idea, but it's maybe me.  
    

That's the reason why I thought of moving the server.rpc classes into
client.xmlrpc.  And since I don't have many classes left in the server
package, I thought of removing the server package and define the
    

"accessor"
  

(name to be changed) hierarchy.
    

Is XML-RPC similar to Java's RMI as far as the general usage structure
(define interface, locate service/object, call methods using stubs)?

If so, the cleanest and most modular way to write this is to have 2
packages.  The first is the server package, which consists of the
interface, the interface implementation, and the server binding class.
The second consists of the interface and the client.  Then, the client
only needs to import the necessary classes for XML-RPC and the
interface, providing a package level separation between the client and
the server with the interface bridging the parameter marshalling gap.

(A similar design was discussed by the writers of "Core Java", in which
they are using RMI to provide the client/server binding)

John