I think reorganizing the structure, see my post on 'Shaking up the Tree' may address some of the issues here.  I agree that clients should be standalone (w/o server package), but code running on the server as an xmlrpc 'service' should not be under the client package.   The client will of course need (available) at least an interface from the 'service' package, to communicate with (and run without ClassNotFoundExceptions).

-Kevin

Vladimir R. Bossicard wrote:
Better yet: let's move all the message names to static final Strings 
somewhere, so that we gain a small point in performance and a huge one 
in cleanliness. How about it?
    

logically, these constants should be stored in the specific class (to gain
modularity), e.g:

    package org.apache.xindice.server.rpc.message;

    public class DeleteDocument {

       public static final String methodname = 
           "org.apache.xindice.server.rpc.message.DeleteDocument";

    }

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.

-Vladimir

=====
Vladimir R. Bossicard
Apache Xindice - http://xml.apache.org/xindice

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

  

Reply via email to