demexp-dev
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]