Redwood wrote:
OK I'm convinced.I would like to have the system property as it allows the XML-RPC library to be debugged at the end-user site without the embedding application having to do anything. The case I had yesterday, I hadn't embedded any specific debugging code and I wanted to use the XML-RPC library debugging, but I couldn't enable it because my application didn't support it.Whether the log instances belong to XmlRpc or another class doesn't really bother me, but I do want to be able to enable them without embedding application support.
I am almost convinced. I am unfamiliar with the functional requirements of an applet developer for our library, but I will accept at face value that an 80% increase in the file size of our applet jar is unacceptable. My concerns would be that the Commons Logging group already put plenty of time into their own "reflection trickery" and we may be able to spend our complexity budget in other places.The reflection trickery is to ensure that the core XML-RPC library is linked against the Log interface and that interface only. If more advanced facilities are available at runtime then they can be used, but I didn't like the idea of forcing applet developers to pull along the entire Commons Logging API and then not use it. This way the production applet only needs one interface (Log) which should be quite small.
We should really formalize our functional requirements for each use case. For example, what is our target filesize for the applet jar? How much memory is the LiteXmlRpcClient allowed to consume? I will spend some time on this in the coming month. I imagine John Wilson is the man to go to for the J2ME stuff. Anyone want to take responsibility for the applet users?
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
