Lsl Xml-rpc

Francky Habercom · 03/02/2009, 19h33

Bonjour,

j'essai d'appliquer ce que j'ai lu ici :
http://rpgstats.com/wiki/index.php?t...P_Implentation

j'obtiens ce message :
Fatal error: Class 'IXR_Client' not found in /home/httpd/MonPseudo/Mondomain/ReqList.php on line 18

la line 18 est

Code PHP:


$client = new IXR_Client('http://xmlrpc.secondlife.com/cgi-bin/xmlrpc.cgi');

Quelqu'un peut-il m'expliquer ?

pour plus de clarté, le code complet :

Code PHP:


<?php
 
if(isset($_GET["idDemandeur"]))
{
 $idDemandeur = $_GET["idDemandeur"];
 
 $monfichier = fopen("monfichier.txt", "r+");
 $mon_uuid = fgets($monfichier);
 fclose($monfichier);
 $ll_packet = array(
   'Channel'     => $mon_uuid,  //Destination Object Key
   'IntValue'    => 2009,
   'StringValue' => $idDemandeur);
 
 // Create the client object
 $client = new IXR_Client('http://xmlrpc.secondlife.com/cgi-bin/xmlrpc.cgi');
 
 // Run a query for PHP
 if (!$client->query('llRemoteData', $ll_packet)) {
    die('Something went wrong - '.$client->getErrorCode().' : '.$client->getErrorMessage());
 }
 
 // Display the result
 echo '<pre>';
 print_r($client->getResponse());
 echo '</pre>';
}
?>

Francky Habercom · 03/02/2009, 19h55

Autre source : http://wiki.secondlife.com/wiki/Cate...XML-RPC/fr#php

Autre code :

Code PHP:


<?php
$idDemandeur = $_GET["idDemandeur"];
if(isset($idDemandeur ))
{
function sendToHost($host,$method,$path,$data,$useragent=0)
{ 
 $buf="";
 // Supply a default method of GET if the one passed was empty 
 if (empty($method)) 
  $method = 'GET'; 
 $method = strtoupper($method); 
 $fp = fsockopen($host, 80, $errno, $errstr, 30);
 if( !$fp )
 {
  $buf = "$errstr ($errno)<br />\n";
 }else
 {
  if ($method == 'GET') 
  $path .= '?' . $data; 
  fputs($fp, "$method $path HTTP/1.1\r\n"); 
  fputs($fp, "Host: $host\r\n"); 
  fputs($fp, "Content-type: text/xml\r\n"); 
  fputs($fp, "Content-length: " . strlen($data) . "\r\n"); 
  if ($useragent) 
   fputs($fp, "User-Agent: MSIE\r\n"); 
  fputs($fp, "Connection: close\r\n\r\n"); 
  if ($method == 'POST') 
   fputs($fp, $data); 
  while (!feof($fp)) 
   $buf .= fgets($fp,128); 
  fclose($fp); 
 }
 return $buf; 
} 
 $monfichier = fopen("monfichier.txt", "r+");
 $mon_uuid = fgets($monfichier);
 fclose($monfichier);
 echo '<pre>';
 $channel = $mon_uuid; //Entrez le channel que vous utiliser (key)
 $xmldata = "<?xml version=\"1.0\"?><methodCall><methodName>llRemoteData</methodName><params><param><value><struct><member><name>Channel</name><value><string>".$channel."</string></value></member><member><name>IntValue</name><value><int>11261979</int></value></member><member><name>StringValue</name><value><string>".$idDemandeur."</string></value></member></struct></value></param></params></methodCall>";
 echo sendToHost("xmlrpc.secondlife.com", "POST", "/cgi-bin/xmlrpc.cgi", $xmldata);
 echo '</pre>';
 
}
?>

et forcement autre message d'erreur :
HTTP/1.1 200 OK
Date: Tue, 03 Feb 2009 18:47:38 GMTServer: Apache/2.0.54 (Debian GNU/Linux) mod_auth_kerb/5.0-rc6 DAV/2 SVN/1.4.2 mod_jk2/2.0.4 mod_python/3.1.3 Python/2.3.5 PHP/5.2.0-8+etch9~bpo31+1 mod_ssl/2.0.54 OpenSSL/0.9.7e mod_wsgi/2.0 mod_perl/1.999.21 Perl/v5.8.4
Content-Length: 255
Connection: close

Content-Type: text/xml

faultStringInvalid channelfaultCode2

Bref, je suis complètement perdu

Francky

Seb_01 · 05/02/2009, 10h52

Je ne vois comment cela peut marcher ??

il te manque la partie gestion XML

Code PHP:



    echo '<pre>';
    $channel = "ICI METTRE LA CLEF DE L'BJET"; 
    $xmldata = "<?xml version=\"1.0\"?><methodCall><methodName>llRemoteData</methodName><params><param><value><struct><member><name>Channel</name><value><string>".$channel."</string></value></member><member><name>IntValue</name><value><int>11261979</int></value></member><member><name>StringValue</name><value><string>happy birthday</string></value></member></struct></value></param></params></methodCall>";
    echo sendToHost("xmlrpc.secondlife.com", "POST", "/cgi-bin/xmlrpc.cgi", $xmldata);
    echo '</pre>';

pour que cela marche il faut que tes channels soient accordés en l'occurrence c'est UUID de l'objet.

Le serveur ne pas la deviner.

Et ne peut accepter n'importe quelle clef.

Les exemples qu'il te donne fonctionnent parfaitement.

[1:37] Object: Request received for REMOTE_DATA_REQUEST 7cc08c43-6cb5-e361-3fb7-5b4954c6c190 00000000-0000-0000-0000-000000000000 11261979 happy birthday
[1:37] Object: I just recieved data in Chieut at position <63.05575, 125.43920, 116.20650>
The string was happy birthday
The number was 11261979.

Magic Cat · 05/02/2009, 13h35

/me tend un tube d'aspirine à francky

vazy Francky c'set bon vazy Franck c'est bon

Ce qui me fait le plus peur dans tout ca, c'est que je crois que tu cherches à réinventer la roue. Par hasard, c'set quand même pas pour faire un système de vendor que tu fais ca?

05/02/2009, 18h03

Citation :

Publié par Magic Cat

/me tend un tube d'aspirine à francky

vazy Francky c'set bon vazy Franck c'est bon

Ce qui me fait le plus peur dans tout ca, c'est que je crois que tu cherches à réinventer la roue. Par hasard, c'set quand même pas pour faire un système de vendor que tu fais ca?

Tien justement je serais curieux de savoir comment font les vendor pour vendre des objet qui ne sont pas dedans avec server.

Magic Cat · 05/02/2009, 22h29

Y a des choses des fois qui vaut mieux pas savoir

Lena F · 06/02/2009, 17h19

Le XMLRPC tend à être supprimé, le wiki le classe même comme "deprecated". Ne pas trop compter dessus...

Citation :

Publié par >>>Rabbit_Boys<<<

Tien justement je serais curieux de savoir comment font les vendor pour vendre des objet qui ne sont pas dedans avec server.

llEmail ou script externe (PHP,...) mais ça renvoie souvent une requête XMLRPC.

Sinon, n'oublie pas d'ajouter une gestion de la pile si ton script sera amené à effectuer deux requêtes à la suite sur le même canal car il y'a une limitation de 3 secondes entre chaque appel.

Magic Cat · 06/02/2009, 17h33

Aller le principe:
- Le vendor envoit comme un info à une page php (rabbit_boys, tee-shirt)
- la page php renvoit une requete xml (rabbit_boys, tee-shirt) à un objet dans second life que l'on appelle "serveur"
- le serveur alors fait un LLgiveInventory à rabbit_boys de tee-shirt.
(car effet c'est le serveur second life qui stock tout les objets)

@lena: parcontre le XML-RPC sera remplacer par autre chose de similaire, car je crois pas que maintenant que LL qui vient de racheter Xstreet qui fonctionne sur ce principe, va tout casser maintenant

enfin moi je dis ca, je dis rien

06/02/2009, 19h12

Citation :

Publié par Magic Cat

Aller le principe:
- Le vendor envoit comme un info à une page php (rabbit_boys, tee-shirt)
- la page php renvoit une requete xml (rabbit_boys, tee-shirt) à un objet dans second life que l'on appelle "serveur"
- le serveur alors fait un LLgiveInventory à rabbit_boys de tee-shirt.
(car effet c'est le serveur second life qui stock tout les objets)

@lena: parcontre le XML-RPC sera remplacer par autre chose de similaire, car je crois pas que maintenant que LL qui vient de racheter Xstreet qui fonctionne sur ce principe, va tout casser maintenant
enfin moi je dis ca, je dis rien

Euh

(Une)Un info a une page Php? donc il me faut quelque choses d'externe a SL?
De quel genre? je dois savoir coder du Php ou Xml? Ro le Lsl suffit pas?
Je savais que c'était pas façile. Qui me donne plus d'info en Mp?

Désolé Franck Lol on se sert de ton Sujet.

Magic Cat · 07/02/2009, 02h55

Ben déjà mon gars, fallait faire comme francky venir à mon cours sur le LSL et internet.

Et pour faire tout ca il te faut connaitre le LSL, php, html et xml.
L'esperanto étant un plus

Nibb · 07/02/2009, 10h11

Citation :

Publié par >>>Rabbit_Boys<<<

Euh

(Une)Un info a une page Php? donc il me faut quelque choses d'externe a SL?
De quel genre? je dois savoir coder du Php ou Xml? Ro le Lsl suffit pas?
Je savais que c'était pas façile. Qui me donne plus d'info en Mp?

Désolé Franck Lol on se sert de ton Sujet.

Si tu veux interfacer un site web à un vendor LSL, ben oui tu es obligé de connaître la programmation Web.

Sinon, non.

Magic Cat · 07/02/2009, 21h36

Citation :

that the service is "deprecated". They suggest using HTTP polling as an alternative.

Dixit lslwiki, mais c'est quoi le HTTP polling???

me dites pas que c'est un serveur qui va consulter une page php avec un timer?

Seb_01 · 07/02/2009, 22h04

Http polling est un processus qui généralement vient du serveur vers les clients leur demandant si ils ont des requêtes.

Magic Cat · 08/02/2009, 00h07

bhen ce que tu decris c'set deja ce qu'il se passe avec le xml RPc, concrètement c'est quoi leur suggestion pour l'alternative.
Tu sais seb?

Freelance Gontineac · 08/02/2009, 07h16

Le HTTP-Polling c'est en fait ton objet 'in-sl' qui vient requèter le serveur de façon régulière ou évenementielle afin de voir si les données qui l'interesse sont a jour, un peu comme quand tu verifies ta boite aux lettres tous les midis pour voir si il y a du courrier.

Quand a xml-rpc c'est peu fiable et quelquefois tres lent...

Nibb · 08/02/2009, 08h42

Si c'est ça, t'as pas intérêt à avoir des milliers d'objets qui viennent interroger le serveur toutes les 30 secondes.

Sinon, j'ai l'impression que le mail, c'est le plus simple.

Seb_01 · 08/02/2009, 08h48

Citation :

Publié par Freelance Gontineac

Le HTTP-Polling c'est en fait ton objet 'in-sl' qui vient requèter le serveur de façon régulière ou évenementielle afin de voir si les données qui l'interesse sont a jour, un peu comme quand tu verifies ta boite aux lettres tous les midis pour voir si il y a du courrier.

Quand a xml-rpc c'est peu fiable et quelquefois tres lent...

Dans le cas de SL c'est exact le SL le HTTP-Polling s'effectue dans le sens Client
Serveur pour une raison simple c'est que les connexions ne sont que "sortantes" SL vers le monde externe (llHTTPRequest) la réponse se faisant par http_response().

Pour ta question en faisant simple

Ce qui est dit:

LSL receives XML-RPC requests and passes them to the prim specified. It may not establish this connection, but it may reply and keep two-way communication with that server. These responses seem to be able to transport the largest amount of data out of Second Life (vs. Email and HTTP Requests).

Ce qui a première vue est "allechant"

mais...

The current implementation of XML-RPC only allows ONE request to be queued on the front-end server (xmlrpc.secondlife.com) at a time. Any additional requests to the same data channel overwrite any pending one. This has serious ramifications for the design of XML-RPC communications where the in-world object could receive requests faster than it can respond to them. In addition, the 3-second delay in llRemoteDataReply exacerbates this problem even more.

l'est moins

Mais

The observed issue is this: if you send multiple quick requests to an in-world object via XML-RPC, one which is scripted to perform some processing and then return a response (via llRemoteDataReply), there is a potential for earlier requests to get lost on the front end server (they still should generate remote_data events, though), and have the response meant for an earlier request end up being passed back to a later one, while the earlier requests will time out back at your external application.
As a result, if you intend to do any serious work with XML-RPC, you will have to design your external client application to manually serialize all requests to each individual RPC channel. That means you have to wait for a response from the previous request before you attempt to send the next one. If you don't care about receiving responses, then this problem is not an issue, as all requests seem to get passed on to the script, regardless of the queueing issue.

Ce qui me semble normal si on programme de façon sérieuse compte tenu des

avertissements mentionnés par LL...

Concernant ta question de "Deprecated" elle me fait sourire... aucun risque que LL l'enlève pour des tonnes de bonne raisons...

ce qui est confirmé par LL dans un thread de

Kelly Linden
Linden Developer

rpc is not quite depricated. We still support it and want to know about any stability, performance or bug issues found with it. It is important to include the following in any report
.....
llHR requests are handled entirely from the host the region is on. There is no central service and the requests themselves are very light weight. There is no dependence on any other service, central or otherwise, besides general network connectivity

We expect XML-RPC to work and will continue to work to support it. However, it is better to use llHTTPRequest whenever possible as it will be more reliable and offer better performance going forward.

Ce qu'oublie de mentionner LL (comme dab quand ils ne sont pas très clair) que qu'un point fort de rpc est qu'il autorise les connexions entrantes Monde externe --> SL...

J'éspère avoir été complet.

Comme l'a dit Freelance Gontineac rpc est fragile et le delai de 3 secondes (mini) peut être un problème.

Seb_01 · 08/02/2009, 09h14

Citation :

Publié par Nibb

Si c'est ça, t'as pas intérêt à avoir des milliers d'objets qui viennent interroger le serveur toutes les 30 secondes.

Sinon, j'ai l'impression que le mail, c'est le plus simple.

Tu as raison Nibb

Bon nombre de requètes externes ne sont pas justifiées pour les raisons suvantes:

1. les scripts internes gardent leur données si ils ne sont resetés et un reset est un acte volontaire...

2. les données des scripts sont conservées MEME quand une région reboot et même quand un objet est repris en inventaire et reposé...

3. les comms possible sont:
les messages linked ( à travers un objet)
les messages à travers la région
et les emails ...

Ce qui dans la quasi totalité des cas est LARGEMENT suffisant pour ne pas avoir à externiser des requêtes.

PS Les emails sont évidement des connexions entrantes/sortantes mais elles sont asynchrones et indirectes.

Freelance Gontineac · 08/02/2009, 09h29

Après tout dépends les besoins effectivement... Et les choix d'architecture que tu fais...

Magic Cat · 08/02/2009, 11h36

Puisse que le sujet est lancé et bien entamé, je vais me lâcher sur les questions.

Donc me voila rassuré sur l'avenir du xml-rpc....

Question en terme de capacité, on peut passer quelle quantité de données? (2Ko?)

Freelance Gontineac · 08/02/2009, 12h33

Tu peux transmettre un entier, et une chaine de caractère dont la taille serait fixée a 255 caractères maximum. Toutefois, le but étant pas trop de passer des données mais comme le nom l'indique de faire un RPC, c'est a dire un appel de procèdure à distance (Remote Procedure Call), donc passer des paramètres. En gros, ça permet à une application externe de piloter ton object "in-sl".

Magic Cat · 08/02/2009, 13h34

SL manquant cruellement d'interface ou alors trop simpliste, j'avais pensé externalisé la partie paramètrage en utilisant une page web.
Donc le principe:
- l'objet envoi sa config par HTTP à une page php qui sauvegarde la config dans un cookie.
- L'utilisateur est redirigé vers la page, la page charge le cookie et indique ainsi la configuration actuelle de l'objet.
- L'utilisateur rentre ses données puis click sur envoi
- La page php envoit une requete RPC avec les données concaténé par des séarateur dans la chaine.

mais 255 caractère ca va etre super tendu. faudra que je pousse un peu les murs c'set tout

j'ai reflechis entre temps....

Simplement renvoyer en RPC un message qui dit machin a bien saisie sa config, tu peux aller la chercher sur la page web
/me se dit "y a pas à dire je suis un génie" ^^

Merci les gars

Magic Cat Alpha & Oméga	/me tend un tube d'aspirine à francky vazy Francky c'set bon vazy Franck c'est bon Ce qui me fait le plus peur dans tout ca, c'est que je crois que tu cherches à réinventer la roue. Par hasard, c'set quand même pas pour faire un système de vendor que tu fais ca?
05/02/2009, 13h35

Magic Cat Alpha & Oméga	Y a des choses des fois qui vaut mieux pas savoir
05/02/2009, 22h29

Magic Cat Alpha & Oméga	Ben déjà mon gars, fallait faire comme francky venir à mon cours sur le LSL et internet. Et pour faire tout ca il te faut connaitre le LSL, php, html et xml. L'esperanto étant un plus
07/02/2009, 02h55

Magic Cat Alpha & Oméga	Citation : that the service is "deprecated". They suggest using HTTP polling as an alternative. Dixit lslwiki, mais c'est quoi le HTTP polling??? me dites pas que c'est un serveur qui va consulter une page php avec un timer?
07/02/2009, 21h36

Seb_01 Alpha & Oméga	Http polling est un processus qui généralement vient du serveur vers les clients leur demandant si ils ont des requêtes.
07/02/2009, 22h04

Magic Cat Alpha & Oméga	bhen ce que tu decris c'set deja ce qu'il se passe avec le xml RPc, concrètement c'est quoi leur suggestion pour l'alternative. Tu sais seb?
08/02/2009, 00h07

Freelance Gontineac Héros / Héroïne	Le HTTP-Polling c'est en fait ton objet 'in-sl' qui vient requèter le serveur de façon régulière ou évenementielle afin de voir si les données qui l'interesse sont a jour, un peu comme quand tu verifies ta boite aux lettres tous les midis pour voir si il y a du courrier. Quand a xml-rpc c'est peu fiable et quelquefois tres lent...
08/02/2009, 07h16

Nibb Alpha & Oméga	Si c'est ça, t'as pas intérêt à avoir des milliers d'objets qui viennent interroger le serveur toutes les 30 secondes. Sinon, j'ai l'impression que le mail, c'est le plus simple.
08/02/2009, 08h42

Freelance Gontineac Héros / Héroïne	Après tout dépends les besoins effectivement... Et les choix d'architecture que tu fais...
08/02/2009, 09h29

Magic Cat Alpha & Oméga	Puisse que le sujet est lancé et bien entamé, je vais me lâcher sur les questions. Donc me voila rassuré sur l'avenir du xml-rpc.... Question en terme de capacité, on peut passer quelle quantité de données? (2Ko?)
08/02/2009, 11h36

Freelance Gontineac Héros / Héroïne	Tu peux transmettre un entier, et une chaine de caractère dont la taille serait fixée a 255 caractères maximum. Toutefois, le but étant pas trop de passer des données mais comme le nom l'indique de faire un RPC, c'est a dire un appel de procèdure à distance (Remote Procedure Call), donc passer des paramètres. En gros, ça permet à une application externe de piloter ton object "in-sl".
08/02/2009, 12h33

Lsl Xml-rpc

Connectés sur ce fil