> 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
