Volkar, John wrote: > I can give a little insight as to why being able to "break" the spec > in regards to transport layer is very desirable in some situations. > > I work with embedded systems and often times need a messaging or RPC > style protocol. I don't know how many different times I've had to > reimplement a fairly low level scheme to do RPC's from a host to a > target. > > Now, with the advent of some embedded tcp/ip stacks and some embedded > http server support on newer devices, it's advantageous to use > something like XML-RPC to talk to them as it get around network > configurations, fire walls, etc. (Could you image an "appliance" > that demanded your firewall settings? Stuff should just work.) > XML-RPC is great for this, you get a human readable "messaging" > scheme over http and you can reuse the message pack/unpack code from > design to design.
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!). > > However... In the embedded world all to often tcp/ip is not a > transport option at all, or adding it to a design breaks cost > targets. In those cases you still need to communicate with the > device, but man it would be great to reuse all that message handling > code again. So why not use the XML-RPC style of message formats, and > handling over things like RS-232, RS-482/5 (which-ever one is > multi-drop, I forget), IEEE1394 (firewire), USB, even shared memory > pipes or just raw (non-http) sockets. So why not? You only need to > use a different transport layer! It not strictly XML-RPC, but it > smells a lot like it. 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). 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. > > And picture this, a "relay/dispatch" device that talks all those > different transports and can "route" XML-RPC calls... Why not? Because the aim of the project is to produce the best Java XML-RPC implementation. I think we should be open to suggestions which make it a better XML-RPC implementation but be very careful about suggestions which make to code useful for other things if that places dependencies on the code which potentially conflict with our prime aim. John Wilson The Wilson Partnership http://www.wilson.co.uk
