Hi, Augustin <[EMAIL PROTECTED]> writes:
> For the sake of argument, what if leaving the server as is (using ONC RPC) > and > creating a library coded in PHP (I cannot help with anything else) IS the > best technical and tactical choice? I can't say. > Do you mean "for" PHP (as in creating a PHP module coded in C) on "in" PHP > (as > in coding a library in PHP that I could integrate into my Drupal module)? I mean "in" PHP. > How hard could that be? > Well, the two important questions are: > 1) what would be the most quickly implemented? A ONC implementation script > coded in PHP, or a rework of your server to handle XML calls? > 2) again, because it is important: what is the best tactical choice over the > long term? Having XML RPC is probably a good tactical option, as a lot of people like this protocol. > From what I understand, the data itself is encoded in XDR: > http://www.ietf.org/rfc/rfc1832.txt Yep. > which is then passed to ONC which will pass the data over to the > server/client > and dialog with it: > http://tools.ietf.org/html/rfc1831 Yes. > and the whole 'dialog' is transported over the net using any transport > protocol, e.g. http. No, the 'dialog' is directly sended over a TCP socket. > So, we have three layers, right? > 1) XDR data > 2) ONC dialog > 3) HTTP transport 3) TCP socket > I am not too worried about the XDR bit: how difficult can it be to put a > string together, using a well defined convention? (but as you pointed out, > the devil might be in the details). XDR is not made of strings but binary data. I'm not sure that PHP has functions do encode/decode binary data. > Supposing I have the XDR data and its ONC wrapper right, I can just use this > to contact the server, get a reply, and finish displaying the page called by > the web interface user, no? Right. > This function can be used if the client wants to "call" the server and get a > reply to a particular question. > What I am not yet clear about, is how would the server "call" the client in > case some events happen that the client needs to be aware of. Currently, the server never calls the client. > The other thing I am not too sure about is the relation between the XDR layer > and the ONC layer. > Browsing the standard description doesn't help much: > > ""11.2 The RPC Language Specification > The RPC language is identical to the XDR language defined in RFC > 1014, except for the added definition of a "program-def" > "" > http://tools.ietf.org/html/rfc1831 ONC RPC is just a description of message format (is it a call? Is it a reply? message format) using XDR, which itself describes translation from/to abstract description (XDR format) to/from binary representation (encoding of bytes on the network). > The two main question remain for you to answer: > 1) which approach would be quicker to implement? I think it would be the XML RPC <-> ONC RPC proxy. > 2) what is the best tactical choice? Create an XML RPC interface. Use the ONC RPC interface on the server side. > I don't feel competent enough to answer any of those two questions. > David (and others): I am waiting for you to make a decision. I've given my point of view. Others may disagree. :-) I'll try to look at the faisability of all of this in the following weeks. Best wishes, d. -- GPG/PGP key: A3AD7A2A David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A _______________________________________________ Demexp-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/demexp-dev
