headers
Augustin | 1 Sep 2006 06:44

ONC RPC for PHP? Re: On web client, XML and ONC RPC and their integration with demexp

David and all,

In my previous email, I stated that re-coding the server to use XML RPC only 
could be the easiest and the best solution in the long term.
It certainly would make things easier for me, if not for you ;).

Honestly, my main concern is NOT to save myself some troubles, but to make the 
right technical choice that we will not regret later (because it is easy to 
maintain, because it is easy to install and to use and thereby attracting 
more developers, etc).

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?

In this mail, then, I try to figure out what it would take.
As you read the following, the extent of my ignorance should become obvious. 
It is important that you know of my limitations so that you know what kind of 
help to expect from me :)
Please be patient with me, and tell me where I am wrong.

On Thursday 31 August 2006 07:48 pm, David MENTRE wrote:
> A second approach would be to implement an RPC generator and its
> supporting XDR encoding/decoding library for PHP. 

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 haven't much 
> investigated this approach but it seems to me not a very simple
(Continue reading)

Permalink | Reply | 3 comments |
headers
Frederic Lehobey | 1 Sep 2006 09:04
Picon
Favicon

Re: ONC RPC for PHP? Re: On web client, XML and ONC RPC and their integration with demexp

Hi,

On Fri, Sep 01, 2006 at 12:44:37PM +0800, Augustin wrote:

> 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?

> 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?

I can hardly answer this question, but one interesting point is that
it would provide a new feature to PHP developpers.

> > Moreover, beside demexp, I don't think a lot of people in the PHP 
> > community are eager to use ONC RPC.
> 
> Most probably true.

It mitigates what I have said just above. But have you looked at the
way XML-RPC are (technically) handled in PHP? Would it be possible to
adapt this existing work?

> As you see, I am willing to have a look at this approach. 

This is precious.
(Continue reading)

Permalink | Reply | 1 comment |
headers
David MENTRE | 1 Sep 2006 12:43
Favicon

Re: On web client, XML and ONC RPC and their integration with demexp

Hello Augustin,

Augustin <beginner2005 <at> masquilier.org> writes:

> The Drupal API is well documented:
> http://api.drupal.org/apis/HEAD/xmlrp

Thank you for the pointers.

> Also how difficult would it be to set up a server for development?

You mean, a demexp server. Quite easy with a static binary or with
Thomas's Ubuntu and Debian packages, a nightmare from sources.

I can easily provide a statically linked version if needed.

> Most of the posts I found discussing the relative merits of the two standards 
> date back to the last 1990s. It seems that this century, everybody accepts 
> XML RPC as the web standard. 

This is not because everybody does the same thing that everybody is
right. :-)

> So, why not use XML RPC only, and announce that once the official server is 
> upgraded, it will stop replying to ONC RP Calls?

Because:

 1. the current code is debugged and tested, with non regression
    tests. Starting from scratch would be a big overhead;
(Continue reading)

Permalink | Reply | 0 comments |
headers
David MENTRE | 1 Sep 2006 13:03
Favicon

Re: ONC RPC for PHP? Re: On web client, XML and ONC RPC and their integration with demexp

Hi,

Augustin <beginner2005 <at> masquilier.org> 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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
David MENTRE | 1 Sep 2006 17:57
Favicon

[hack] basic structure for an XML RPC <-> ONC RPC proxy for demexp in Python

Hi,

I've played a bit with XML-RPC server API in Python[1] as well as with
Thomas's RPC binding for demexp[2] and I succeeded in hacking the start
of a basic XML RPC <-> ONC RPC proxy for demexp (see the joined Python
code).

Example of use (in Python):
>>> from xmlrpclib import *
>>> server = ServerProxy("http://localhost:50001")
>>> server.login("demo","demo")
27948569
>>> server.max_question_id(27948569)
270
>>> print server.question_info(27948569, 0, 3)
[{'q_id': 2, 'q_info_num_votes': 4, 'q_info_limit_date': 0, 'q_desc': u"Le but de toute association
politique est la conservation des droits naturels et imprescriptibles de l'Homme. Ces droits sont la
libert\xe9, la propri\xe9t\xe9, la s\xfbret\xe9, et la r\xe9sistance \xe0 l'oppression.",
'q_info_elected_responses': [1], 'q_timestamp': 20648718, 'q_info_status': 2,
'q_info_responses': [{'r_info_desc': 'Question rejected', 'r_info_link': ''}, {'r_info_desc':
u"D'accord pour reconna\xeetre ce droit.", 'r_info_link':
'http://www.conseil-constitutionnel.fr/textes/d1789.htm'}]}, {'q_id': 1, 'q_info_num_votes':
9, 'q_info_limit_date': 0, 'q_desc': u"Les hommes naissent et demeurent libres et \xe9gaux en droits.
Les distinctions sociales ne peuvent \xeatre fond\xe9es que sur l'utilit\xe9 commune.",
'q_info_elected_responses': [2], 'q_timestamp': 16804478, 'q_info_status': 2,
'q_info_responses': [{'r_info_desc': 'Question rejected', 'r_info_link': ''}, {'r_info_desc':
u"D'accord pour reconna\xeetre ce droit", 'r_info_link':
'http://www.conseil-constitutionnel.fr/textes/d1789.htm'}, {'r_info_desc': u"Je
pr\xe9f\xe8re la r\xe9daction \xab Les humains naissent et demeurent libres et \xe9gaux en droits. Les
distinctions sociales ne peuvent \xeatre fond\xe9es que sur l'utilit\xe9 commune. \xbb",
(Continue reading)

Permalink | Reply | 502 comments |
headers
David MENTRE | 1 Sep 2006 18:14
Favicon

Re: [hack] basic structure for an XML RPC <-> ONC RPC proxy for demexp in Python

David MENTRE <dmentre <at> linux-france.org> writes:

> I join the network XML encoding for the last call,
> question_info(27948569, 0, 3), that shows how things are done at the
> network level.

And for the curious, the total exchanged size for the above XML RPC is
6520 bytes while the same request in ONC RPC is about 1280 bytes (5
times smaller, and about 3 times less network packets). I said that ONC
RPC was more efficient, didn't I? ;-)

Best wishes,
d.
--

-- 
GPG/PGP key: A3AD7A2A David MENTRE <dmentre <at> linux-france.org>
 5996 CC46 4612 9CA4 3562  D7AC 6C67 9E96 A3AD 7A2A
Permalink | Reply | 501 comments |
headers
GISQUET Christophe | 2 Sep 2006 18:01
Picon
Favicon

Newer clients under win32 platform

Hello,

I've just tried to quickly reinstall a build environment suitable for demexp 
and managed to produce some installers, as usual available at 
http://christophe.gisquet.free.fr/demexp/

While 0.6.3 went as expected like a breeze, 0.7 versions were a total PITA, in 
particular for gettext support (yay for ocaml!): the number of dependencies is 
ludicrous. Which by the way does not work, but more on this later.

So we have:

0.6.3 which is alike the previous versions, except for the installer which has 
the demexp:// URI and desktop shortcut suggested on some page of the website.

0.7-dev which corresponds to some demexp--0.7-dev I saw on David's demexp 
page, and for which I forced my way through gettext by sed'ing away s_/f_/open 
  Gettext. It works, albeit the i18n support is of course not getting in the way.

0.7-22778c97efe4 (an automatically generated tarball) is the real killer here: 
- building gettext requires an ocaml 3.09 version; I'll start a specific 
thread on that matter
- the DemexpGettext module does let dir = None (equivalent to 
$prefix/share/locale ?) which I suspect won't work under windows
- I couldn't understand how to simply build the .mo files from the makefile, 
and had to do a cd po; make -f ../Makefile fr.mo (yay for the new perl 
dependency btw)
- the binary stops (not a crash, gdb shows an exit code of 2 without crash) 
after the anonymous message box; it's probably not related to gettext, so I'll 
start yet another thread for it
(Continue reading)

Permalink | Reply | 1 comment |
headers
GISQUET Christophe | 2 Sep 2006 18:29
Picon
Favicon

Depencies of ocaml-gettext and other problems

Hello,

to quote myself:
 >  the number of dependencies is ludicrous

While those dependencies are unavoidable, one has to waver through various 
intricates problems:

1) camomile, if I remember well, uses an option containing "pack", which is 
not supported by 3.08 versions, incidentally the one packaged for cygwin. In 
addition, one may end up being gratified with "'stuff1' and 'stuff2' disagree 
on 'some' interface", which is a another convoluted way of giving the 
convoluted explanation "incompatible ABIs somewhere". This means that for all 
packages having this problem, one must rebuild them with the 3.09 version one 
would have recompiled. That hurts, doctor.

1') Funny thing (and of no use to this list), some packages have:
- a build-dir option specifying where *all* files will be put
- make performs the bytecode build/native build/installation in one step into 
the given folder
- make clean wipes this directory...
So, if, for some reason, like incompatible APIs, you think of doing a make 
clean, don't complain to the doctor that specifying $HOME or the 
world-writable /usr hurts.

2) Most links from the configure are broken
For instance links starting with http://webperso.easyconnect.fr/gildor are now 
hosted at http://www.gallu.homelinux.org/projects.html
Then, some may have interface problems or not (see a mail on this very list 
involving TyRec), leading to "where are the *latest* versions?". The only
(Continue reading)

Permalink | Reply | 22 comments |
headers
Augustin | 3 Sep 2006 08:36

Re: ONC RPC for PHP? Re: On web client, XML and ONC RPC and their integration with demexp

Hi Frédéric,

Thanks for stopping by and cheering us up :)

On Friday 01 September 2006 03:04 pm, Frederic Lehobey wrote:
> It mitigates what I have said just above. But have you looked at the
> way XML-RPC are (technically) handled in PHP? Would it be possible to
> adapt this existing work?

Yes, I did start. I had to, anyway, because if it was not ONC RPC, it would be 
XML RPC.

Anyway, the point is moot, now: it seems that David has chosen the proxy 
solution, so I don't need to care at all about ONC RPC.

David's choice actually make my job easier :)

Thanks,

Augustin.

--

-- 
http://www.wechange.org/
Because we and the world need to change.

http://www.reuniting.info/
Intimate Relationships, peace and harmony in the couple.

http://www.gnosis-usa.com/
Revolutionary Psychology, White Tantrism, Dream Yoga...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Augustin | 3 Sep 2006 09:05

Does the server need to call the client?

On Friday 01 September 2006 07:03 pm, you wrote:
> > 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.

I am not sure if the server needs to call the client or not.

Here is the situation I am thinking about.

I will pull all the public data from the server (all the questions, and  the 
answers, nb of votes and elected choice). I will create a "node" (a page of 
content in the Drupal lingo) for each question. The node will be displayed to 
anonymous users, and for the search engines to index.

The nodes (questions) will be updated each time a registered user uses the web 
client to submit an answer, or cast a vote.

The problem is that the web client cannot know of the activity going on 
between the server and all the hard clients.

I was thinking that the server could be set up to 'call' (via xml rpc) the web 
client, whenever another client is updating the data. This way the web client 
knows it needs to update its own internal records. 

Now, I understand that this particular way of doing might be troublesome for 
you (requires much more coding). 
There is a probably much better way to do it, that would never require the
(Continue reading)

Permalink | Reply | 501 comments |

Gmane