initial load of upstream version 1.06.32
[xmlrpc-c] / doc / TODO
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
6
7 FUNCTIONAL CHANGES
8 ------------------
9
10 Make xmlrpc_server_abyss() catch a SIGTERM and terminate cleanly.
11
12 Make a system.shutdown XML-RPC method to send SIGTERM to its server.
13 Don't know what kind of security.
14
15 Provide an interface for Abyss servers where the user accepts the TCP
16 connection and passes to Xmlrpc-c the open socket.  This would be
17 useful for inetd servers, among others.  For the C++ interface, this
18 should be a new constructor option to create a server with no socket
19 and a doRpc() method that has a connected socket as parameter.
20
21 Put details in the manual for the xmlrpc-c/server_abyss.hpp interface:
22 libxmlrpc_server_abyss++.html.
23
24 Implement pluggable XML transports on the server side like on the
25 client side.
26
27 Create a non-XML non-HTTP efficient transport, client and server.
28 The tools/binmode-rpc-kit/ directory might be useful.  Consider XDR.
29
30 Make clients and servers reentrant (this requires getting or making
31 reentrant HTTP libraries).
32
33 Change the argument order of asynchronous response callbacks to be
34 more consistent with the xmlrpc_client_call_asynch function.  Also
35 take a look at the server method callback.
36
37 Make an optional destructor function for XMLRPC_TYPE_C_PTR.
38
39 Return XMLRPC_LIMIT_EXCEEDED_ERROR when nesting limits are exceeded.
40 This will break binary and source API compatibility in a very minor
41 way.
42
43 Make a Perl interface to Xmlrpc-c libraries.  This would be better than the
44 existing Perl RPC::XML modules because the latter are Perl all the way down
45 to the sockets and are thus very slow.
46
47 Don't use xmlrpc_value for things that aren't part of an XML-RPC call or
48 response.  It's confusing.  In particular, we use an xmlrpc_value
49 array to pass the parameters of an RPC to xmlrpc_client_call(), and it
50 should instead be a normal C array plus count, or variable argument list.
51
52 Don't use XML-RPC fault codes internally.  It's confusing.  Plus, there's
53 no need for fault codes at all.  Just use the string descriptions.
54
55
56 IMPLEMENTATION CHANGES
57 ----------------------
58
59 Replace dynamically created make files with static ones based on GNU make.
60
61 Use function pointers to access cleanup code in xmlrpc_DECREF?
62
63 Or even better: Should we create some kind of class-like system to declare
64 XML-RPC types, with a per-type dispatch table?
65
66 Fix abstract XML parser API to access children via functions named
67 xml_element_child(env,elem,index) and xml_element_child_count(env,elem).
68 Clean up corresponding client code.
69
70 Make the C++ server implementation less based on the C functions.
71