I want to write an XINETD service that can use XMLRPC++.
From what I can tell, the XMLRPC++ code is setup pretty tightly to assume that it will be using sockets, and that the application will be a "daemon" style application that will sit in a "wait" until a client request comes in.
Of course, under XINETD both these assumptions would be wrong: XINETD would be handling the socket activity, and it would be firing up my app only after a client request came in, negating the need for my service to "wait".
So I guess my question is this: Are there simple hooks to change the above assumptions that XMLRPC++ is based on.... and if not, has anyone hacked into the code to make it more usable in a XINETD world?
Alternatives to hacking the code to make it work might be just ditching it as is and instead stealing useful pieces of its code like its HTTP handling and XML parsing, which, essentially, is a lot of the core of the XMLRPC++ technology.
Thanks for any input you might have!
Michael
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I want to write an XINETD service that can use XMLRPC++.
From what I can tell, the XMLRPC++ code is setup pretty tightly to assume that it will be using sockets, and that the application will be a "daemon" style application that will sit in a "wait" until a client request comes in.
Of course, under XINETD both these assumptions would be wrong: XINETD would be handling the socket activity, and it would be firing up my app only after a client request came in, negating the need for my service to "wait".
So I guess my question is this: Are there simple hooks to change the above assumptions that XMLRPC++ is based on.... and if not, has anyone hacked into the code to make it more usable in a XINETD world?
Alternatives to hacking the code to make it work might be just ditching it as is and instead stealing useful pieces of its code like its HTTP handling and XML parsing, which, essentially, is a lot of the core of the XMLRPC++ technology.
Thanks for any input you might have!
Michael