Hi !
I am playing around with xml-rcp with idea to use it someday on
some real application. I asked once or twice about the project roadmap,
on mailing list but no direct answer. So I'll try to think "loud". I think
that most
of the problems I have are either already solved, or bother other people
also,
so we can fix it. Please forgive me, since I have C++ background and I am
only
a java beginner.
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.
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.
3. logging
Logging is implemented via System calls. Log4j is much stronger. Some
reason
except recoding time, to not use it?
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.
I am stil searching for a way to laod the class really on demand. Any
suggestions?
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.
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 ?
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'd really appreciate the answer.
Matjaz
P.s. The extensions I wrote are available upon request. I'd rather not to
send them to the mailing list.
