* This library uses its own XML parser. And it obviously contains bugs. It, in particular, does not handle tags like <array/> (there was patch concerned this but it did't integrated into distribution).
* It also has quite poor XML-RPC sanity check. If you would pass <int>X</int> tag to it you will get no exception but completely empty request on server side. It adds difficulties into debuging/testing process and reduces stability.
Interface issues:
* XmlRpcValue is converted to almost any requested type without warning. So it does not provide type-safety.
* Implementation of XML-RPC struct type creates a member with default value on try of accessing of unexistent member. So it does not enforce parameters checking, which in turn cencourages error-prone code. Especially in projects with many developers.
* Uncomfortable array interface: one should explicitly set size of array before filling it.
* ...
Missed features:
* Multithreading.
* Secure connections.
* XML parser does not support UTF-8.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree with you, these are unresolved bugs, but I do not know if they are so critical as you mention.
In my opinion, it depends on which kind of application you are developeing. In my case, I use XmlRpc++ lib for embedded linux, with limitations like only one client connected at the same time, a second timeout included, ... In this scenario:
- Own XML Parser: it is an advantage. Including a XML parser lib would mean another lib to port, compile, etc. And the size: a lib like libxml2 is about 2MB. And in a 16MB Flash that means a huge procent (even if it is compressed in flash)
- Sanity check: you are right, that is, in my scenario a bug to consider. But I do not work in "open networks"
- Secure connections: in our scenario, not an issue
- Arrays issue. Simply, we do not use them.
As final comment, yes, there are bugs (lots of them, others not included in your list are the one that cause US real problems), but the lib is small and compact, and therefore, in my opinion, proper to embedded systems.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok. May be you right about embedded systems here. Perhaps, indeed there is no enough good free software for remote communications for embedded systems. I.e. this library can be choosen according to principle of lesser evil.
About external XML parser... I believe that one can build minimal version of libxml2 that would be much lesser than its default size. E.g. OpenZaurus' libxml2 copressed package takes 304kb and about 700kb when installed.
Moreover, according to your post (if I understand right) you do not use XML-RPC for open communications. I.e. clients and servers are controlled by you. This is quite rare case and (IMHO) good XML-RPC library should consider different situation by default. Thus, it should allow to write secure and effecient code for remote communication in a straightforward way.
Thank you for discussion too :)
Anton
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It seems version 0.7 has been released more than 2 years already.Are you continuing developping? Why I can't browser CVS repository?
I think that development was stoped with version 0.7. There were some patches from other people, which still not incorporated in main tree.
This library has several serious unresolved bugs so I would suggest you choose another one.
Hi,
which do you mean with "everal serious unresolved bugs"? I am using this lib and it is interesting to know that info!
Regards
Here is some bugs that I can quickly recall:
* This library uses its own XML parser. And it obviously contains bugs. It, in particular, does not handle tags like <array/> (there was patch concerned this but it did't integrated into distribution).
* It also has quite poor XML-RPC sanity check. If you would pass <int>X</int> tag to it you will get no exception but completely empty request on server side. It adds difficulties into debuging/testing process and reduces stability.
Interface issues:
* XmlRpcValue is converted to almost any requested type without warning. So it does not provide type-safety.
* Implementation of XML-RPC struct type creates a member with default value on try of accessing of unexistent member. So it does not enforce parameters checking, which in turn cencourages error-prone code. Especially in projects with many developers.
* Uncomfortable array interface: one should explicitly set size of array before filling it.
* ...
Missed features:
* Multithreading.
* Secure connections.
* XML parser does not support UTF-8.
First of all, Anton, thanks for your feedback.
I agree with you, these are unresolved bugs, but I do not know if they are so critical as you mention.
In my opinion, it depends on which kind of application you are developeing. In my case, I use XmlRpc++ lib for embedded linux, with limitations like only one client connected at the same time, a second timeout included, ... In this scenario:
- Own XML Parser: it is an advantage. Including a XML parser lib would mean another lib to port, compile, etc. And the size: a lib like libxml2 is about 2MB. And in a 16MB Flash that means a huge procent (even if it is compressed in flash)
- Sanity check: you are right, that is, in my scenario a bug to consider. But I do not work in "open networks"
- Secure connections: in our scenario, not an issue
- Arrays issue. Simply, we do not use them.
As final comment, yes, there are bugs (lots of them, others not included in your list are the one that cause US real problems), but the lib is small and compact, and therefore, in my opinion, proper to embedded systems.
Ok. May be you right about embedded systems here. Perhaps, indeed there is no enough good free software for remote communications for embedded systems. I.e. this library can be choosen according to principle of lesser evil.
About external XML parser... I believe that one can build minimal version of libxml2 that would be much lesser than its default size. E.g. OpenZaurus' libxml2 copressed package takes 304kb and about 700kb when installed.
Moreover, according to your post (if I understand right) you do not use XML-RPC for open communications. I.e. clients and servers are controlled by you. This is quite rare case and (IMHO) good XML-RPC library should consider different situation by default. Thus, it should allow to write secure and effecient code for remote communication in a straightforward way.
Thank you for discussion too :)
Anton