[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

ME: A tale of two paradigms


Greetings Enhydra ME developers,

If you've been watching the list over the last few weeks, then you know that we are in the process of releasing an XML-RPC implementation for the EndhyraME platform. As such, the subject has come up as to how this should be integrated with the rest of the platform. Via a traditional democratic vote, the EnhydraME community agreed that an XML-RPC implementation offered added value, rather than a competing standard to the existing SOAP implementation (ksoap). Excellent!

There is, however, another integration issues worth discussing. When I first wrote the kxmlrpc source, I used the MinML XML parser -- http://www.wilson.co.uk/xml/minml.htm (about 8kb) which is SAX-based. When combined with the SAX classes, it comes in at around 13kb (2-3 kb smaller than the minimum kxml). So the question becomes, should kxmlrpc adopt kxml as its parsing engine, maintain a SAX-based interface, or support both?

The argument has been raised that maintaining two versions would be too cumbersome and that kxml and SAX employ radically different parsing paradigms (pull-based vs push-based). Perhaps this is just my ignorance with respect to the architecture of pull-based XML parsing, but I don't see that these models are radically different. Last night, as an experiment I modified my kxmlrpc code to use kxml rather than SAX. I was able to modify my SAX-based kxmlrpc implementation into a kxml-based implementation in about 20 minutes, by adding a single recursive routine and commenting out a half-dozen SAX-specific lines. I simply had my kxml recursive routine call the SAX event methods (startElement(), endElement(), etc.).

So the question remains, what parsing model should be adopted? It has also been suggested that using KSoap's serialization interface (KvmSerializable class) would offer EnhydraME developers the flexibility to switch between a SOAP implementation and an XML-RPC implementation at runtime. This is a very interesting idea that deserves further research. I intend to examine this possibility over the weekend and give a full report next week on the feasibility of this approach.

Well, there you have it, that's where we are right now on the kxmlrpc implementation. We encourage your feedback on this particular issue, or any ideas or concerns that you have related to the vision and direction of the EnhyrdaME platform.

Have a great weekend.
 
Cordially,
 
 Kyle Gabhart
  Kxmlrpc Project Chair 
    EnhydraME
 ___________________________
  Director of Java/EJB Division
    Objective Solutions, Inc.
 ___________________________