John Wilson wrote: > That's why I wrote MinML-RPC (http://www.wilson.co.uk/xml/minmlrpc.htm) > which is a small footprint XML-RPC implementation which is currently > being used for industrial process control and is running in Jacuzzis > and toasters (really!).
Just goes to show, nothing in the world is really new. I'll definitely be looking into it. But I'm not using java as the embedded side language, rather standard C and some C++ depending on the target environments. > Yes but the sort of constraints that small scale embedded systems currently > put on the way that Java code is developed (minimising classfile size by > reducing the number of classes, being paranoid about heap usage, having to > stick to Personal Java/ J2ME MIDP language subsets) make the reuse of code > developed for J2SE and above a non starter (oddly you can often go the other > way - code I wrote for 512Kb 8051 systems is now running on 64Gb 32 processor > Sun systems and is used because it's faster than J2SE developed versions). Who said the embedded side would be written in java at all? All I want is a stable well documented message format/protocol which is what XML-RPC is, no matter what the implementation language is. Isn't implementation independence one of the main points of the XML-RPC specification? > I really don't think it's a good idea to add a constraint to a part of the Apache > XML-RPC project that it be useable on small embedded Java systems. We already have > a significant slice of our user population which would like to drop some Applet > support in favour of using the newer collection classes. The project seems to me > moving in the opposite direction from the way in which you would like it to go. I wholeheartedly agree. The Apache distribution of XML-RPC should NOT be constrained, but when a design choice either grants or takes away flexibility, then I DO care. Give me the flexibility to add my own non-spec compliant Transports. If that's not possible, then I either have to hack the distribution to make it so (thus disconnecting my self and my work from the mainline), or find a different implementation to use. Thanks for the reply, John Volkar Senior Software Development Engineer Mckesson APS Research & Development 1-412-209-3828 ---- Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
