2
0

TODO 2.2 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960
  1. Here are some changes we'd like to see to Xmlrpc-c. While it's unlikely
  2. anyone will ever do them, the list is at least useful as an indication of
  3. what direction the maintainer wants the package to take, and that should
  4. be useful to anyone proposing changes of any kind.
  5. FUNCTIONAL CHANGES
  6. ------------------
  7. Put details in the manual for the xmlrpc-c/server_abyss.hpp interface:
  8. libxmlrpc_server_abyss++.html.
  9. Implement pluggable XML transports on the server side like on the
  10. client side.
  11. Create a non-XML non-HTTP efficient transport, client and server.
  12. The tools/binmode-rpc-kit/ directory might be useful. Consider XDR.
  13. Change the argument order of asynchronous response callbacks to be
  14. more consistent with the xmlrpc_client_call_asynch function. Also
  15. take a look at the server method callback.
  16. Make an optional destructor function for XMLRPC_TYPE_C_PTR.
  17. Return XMLRPC_LIMIT_EXCEEDED_ERROR when nesting limits are exceeded.
  18. This will break binary and source API compatibility in a very minor
  19. way.
  20. Expand the Perl interface to Xmlrpc-c libraries to do server functions.
  21. Maybe match some other features of RPC::XML.
  22. Don't use xmlrpc_value for things that aren't part of an XML-RPC call or
  23. response. It's confusing. In particular, we use an xmlrpc_value
  24. array to pass the parameters of an RPC to xmlrpc_client_call(), and it
  25. should instead be a normal C array plus count, or variable argument list.
  26. Don't use XML-RPC fault codes internally. It's confusing. Plus, there's
  27. no need for fault codes at all. Just use the string descriptions.
  28. Add a function to deregister a method from a method registry.
  29. Add a "registry" type that works via a filesystem directory. There is
  30. a .so file for each method with its code, and probably a configuration
  31. file. Make it dynamically updatable.
  32. IMPLEMENTATION CHANGES
  33. ----------------------
  34. Use function pointers to access cleanup code in xmlrpc_DECREF?
  35. Or even better: Should we create some kind of class-like system to declare
  36. XML-RPC types, with a per-type dispatch table?
  37. Fix abstract XML parser API to access children via functions named
  38. xml_element_child(env,elem,index) and xml_element_child_count(env,elem).
  39. Clean up corresponding client code.
  40. Make the C++ server implementation less based on the C functions.