[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ONC RPC for PHP? Re: [Demexp-dev] On web client, XML and ONC RPC and
From: |
David MENTRE |
Subject: |
Re: ONC RPC for PHP? Re: [Demexp-dev] On web client, XML and ONC RPC and their integration with demexp |
Date: |
Fri, 01 Sep 2006 13:03:53 +0200 |
User-agent: |
Gnus/5.1006 (Gnus v5.10.6) Emacs/21.4 (gnu/linux) |
Hi,
Augustin <address@hidden> 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 <address@hidden>
5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A