Re: new & old ideas

[Daniel Rall <dl...@finemaltcoding.com>]

<ma...@zrs-tk.si> writes:

> 1. strings in non latin-1 encodings
>
>     In Slovenia we use latin-2 > encoding. With xml-rpc is necessary
>     to make a minor hack in source > code to work it, but mainly
>     because there is no public methods to do > it a proper way. I
>     really prefer to subclass instead of hack & > recompile.

I just made some changes to CVS HEAD to (hopefully) help with the
encoding issues.  org.apache.xmlrpc.XmlWriter (just separated from the
main XmlRpc class) now actually honors the encoding set by
XmlRpc.setEncoding(String).

If you have other suggestions on this front, by all means offer them.

> 2. interceptors & introspection patch
>
>     Both patches are available for > latest xml.rpc version. What is
>     the reason that they are not > integrated in the main code line? 
>     They are IMHO really usefull.

They're quite large.  I didn't notice any associated test code, and we
don't have a full enough suite of regression tests yet to risk changes
of that size without thorough testing, which in turn takes a lot of
time.

> 3. logging
>
>     Logging is implemented via System calls. Log4j is much >
>     stronger. Some reason except recoding time, to not use it?

Commons Logging or Log4J would be great, but would necessitate an
external dependency.  The XML-RPC packages currently has zero external
dependencies, which is a big plus IMHO.

> 4. Dynamic class loading
>
>      With current version it is necessary to > fix the server code
>      any time you'd like to add a new handler for the > server. I
>      have a working version where is the list of server classes >
>      defined in xml file. The file is read upon startup, and classes
>      are > loaded into server's memory. No need to manualy add
>      handlers and > recompile the server.

You can already add handler dynamically.  See the following method:

  XmlRpcServer.addHandler(String handlername, Object handler)

> 5. Client source code generation
>
>     The xml-rpc call is quite simple on client side. One vector
>     entry for each actual parameter and a xml.rpc call. Nothing
>     hard, but just imagine an application with 100 handlers.  That
>     lead to 500-600 lines of hand written code. On the other hand it
>     can be just one line.
> 
>     Through introspection or directly through xml file (see 4) it is
>     possible to generate this few lines per call. Real application
>     just import a proper generated class file.
> 
>     I've implemented it through introspection, and I get one file
>     for each class, but it can be one file also. The same thing is
>     done in CORBA from IDL files. So it should be a proven concept.

I haven't hit this use case yet.  I'm not saying it's not valuable,
just that I'm not going to spend a lot of time on it myself.

> 6. Incoming queue
>
>     When request arrives to the server, the server launches a new
>     thread or use some existing.  This way is not safe and
>     rational. The reasons are obvious. The model with one incoming
>     thread which puts requests in a queue, and a limited number of
>     workers that service the requests from the queue should be a
>     better model. With sockets that is not so hard to implement
>     it. What are the reasons for the current implementation ?

Ask Hans, it's his code.  Elaboration and examples on improvements to
the design welcome.

> 7. Monolitic structure
> 
>     The server uses inner classes quite a lot. What is the reason? 
>     I'd > prefer to have more open structure when developer can
>     replace some parts with own code (via > subclassing or
>     parametrization).  I am working on seassons. It seems that I'll
>     have to replace a rather > big chunk of code in the existing
>     server to achieve it. With open structure one could just >
>     configure seasson or seassionless server or replace parts or
>     whole request receiver or worker.

I'm not a fan of the monolithic structure, and just recently separated
out a couple of inner and child classes from the main XmlRpc class.
Patches which faciliate the decoupling would be appreciated.
-- 

Daniel Rall <dl...@finemaltcoding.com>