> 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 problem is that SOAP requires namespaces and many many other applications require mixed content. Thus, it seems very difficult to size down kXML further. > 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.). Now the interesting question is: Would it be possible to reduce the overall size significantly by supporting the pull paradigm more directly? I assume in startElement(), you first look up the current program state in order to determine which elements are allowed etc. Using a pull parser, this usually can be reflected by the current program state instead of an explicit state model. This MAY save some time and code, depending on the actual XML format used.... Is the kxmlrpc source code available for download somewhere? BTW: Trying to convert kSOAP the other way around without using a second Thread may show some of the non-trivial differences of the parsing paradigms ;-) Best, Stefan |