Ok. 8-)

Premiers tests satisfaisants, mais depuis certains sites:
URL file-access is disabled in the server configuration in /www/xxxx/x/xxxxxx.xxxxx/x/x/xxxxx/site/pwg/include/functions_xml.inc.php on line 91

Normal, je m'y attendais un peu.

Je continue pour l'instant dans les tests, je complète les contrôles...
J'attaque en suite l'admin de web service.

Reste l'appel à revoir... AJAX?

L'appel via

fopen('http://domain.tld/pwg/service.php?type=random&number=3','r');

marche très bien.
Je me dis simplement que pour exemple d'utilisation, on peut proposer un appel via un Javascript.
Cela ne me paraît pas compliqué.
Donc 2 modèles d'intégration, un tout simple purement php, un second utilisant la méthode AJAX.

Quand penses-tu ? Trop compliqué...
Support trop complexe par la suite?
Merci de ton avis.

Vincent, où en es-tu ? As-tu quelque chose de fonctionnel ? Veux-tu de l'aide ? Ne crois-tu pas que tu développes trop de fonctionnalités pour une première version ?

Merci, nicolas,  je vous finis un petit exemple de demande.

Cela marche et je le fais sous forme de MOD comme demandé par z0rglub.
Le module de service est déjà sur mon site (.../pwg/xml_service.php)

Un exemple temporaire d'appel: Démonstration
Il recherche 8 images en portrait.

Si vous appellez mon site, vous n'aurez (sauf demande) de 1-3 thumbnails en MOD Random uniquement.

Pour l'appeler (le mien):

<?php
// PhpWebGallery Web Service Sample
// No include from PhpWebGallery
// Keep in mind that Dir maybe unavailable on an external site
/*
$xml = getXmlCode
  ( 'http://www.myweb.service.zon/pwg16/'
          .'xml_service.php?'.
        'type=portraits&limit=2' );
*/

$xml = getXmlCode
  ( 'http://.....fr/pwg/'
          .'xml_service.php?'.
        'type=portraits&limit=8' );
// Note: You need to be authorised by the web service owner 

// Here below is just for sample.... 
        
...

// get_CodeXML places the content of a text file in a PHP variable and
// return it. If the file can't be opened, returns false.
function getXmlCode( $filename )
{
  $file = fopen( $filename, 'r' );
  if ( !$file )
  {
    return false;
  }

  $xml_content = '';
  while ( !feof( $file ) )
  {
    $xml_content .= fgets( $file, 1024 );
  }
  fclose( $file );
  $xml_content = str_replace( "\n", '', $xml_content );
  $xml_content = str_replace( "\t", '', $xml_content );

  return $xml_content;
}

   
?>

z0rglub a écrit:

Dans la version actuelle des spécifications (version du 2006.01.17 20:33), je ne vois pas la possibilité assez basique de récupérer les informations d'une liste d'éléments dont on connaît les identifiants.

Mon objectif personnel étant de pouvoir afficher dans un billet de mon blog la miniature d'une photo que j'aurai choisi dans ma galerie. Cette miniature pointerait vers la page picture.php dans la galerie.

(J'ai bien failli ne pas voir ton message... Heureusement je suis abonné).
C'est trop simple effectivement.
On peut demander une catégorie (donc une catégorie virtuelle), donc une liste...

Mais si tu veux une autre forme de requête??? Demande ce que tu veux, je prends toutes les idées?

$xml = getXmlCode
  ( 'http://www.myweb.service.zon/pwg16/'
          .'xml_service.php?'.
        'type=listcat&limit=5&cat=26' );

Adopté: mais je ne sais pas si ce sera inclu ce soir...
(Je me doutais de ce type de demande).

L'inconvénient de ce type de demande est si le service est trop ouvert... L'aspiration totale des photos publique du site...
for ($i=1;$i<2000;$i+=5)
{
  $list='';
  for ($j=$i;$j>($i+5);$i++)
  {
     $list .= $j;
   }
  ?type=list&list=$list;
//  Exploitation
}

Grace au compteur d'images de la galerie, la limite (ici 2000) est connue.
Voila pourquoi j'ai expliqué dès le début à MBt (de mémoire) que la liste devait être gérée (maîtrisée) par le site qui ouvre son service.
D'où le besoin de catégories virtuelles cachées... Ce qui simplifie la programmation de 2000%.

Principes de la maîtrise par catégorie virtuelle cachée:

1er cas. Requête d'un non partenaire (accès libre) => on peut forcer la catégorie cachée "nonpart" (ids=5,6,23,48,56,76,78,98,126), sachant que le maxreturn (devenu ws-limit) s'applique.

2eme cas. Requête de mon partenaire (mon blog) => une (autre) catégorie "monblog" cachée (ids=1,2,3,,4,5,6,7,8,9,....,2000), sachant que dans sa clé d'accès gérée par des dates on trouve sa "limit" et quelle peut être à 25.

Ce qui permet de demander (dans les 2 cas mais évidemment cat=76 n'est pas la même suivant le cas):

?type=list&list=23,42,90&cat=77
?type=list&list=23,42,90,125,178,298&cat=76
?type=random&cat=76&limit=10

(ws-limit à 3)
Résultats du 1er cas (libre) => photo 23 pour les 2 premières requêtes et 3 photos de "nonpart" pour la dernière(*).
(*) La première requête demande la cat 77, oui, mais dans la table des clés d'accès je peux lui forcer la catégorie 76.

Résultats de l'accès de "mon blog" => les requêtes renvoient 3, puis 6, puis 10 photos(*).
(*) En supposant que la catégorie 77 contiennent des photos publiques dont les 23,42 et 90.

Tout ceci marche(*) déjà sauf que la catégorie 76 est visible sur ma galerie et cela ne correspond pas au besoin de ma galerie.
(*): j'ai un petit bug sur l'analyse de clé (clé qui a évoluée).

Pour revenir à ta demande, j'ai deux solutions soit je livre avec list= et je livre en plus un patch (MOD) qui casse list=.
Ou je livre mais list= est en commentaire, pour ceux qui le souhaitent.
A moins que tu me proposes une solution sécurisée (une autre bonne idée).

Je penche pour la solution '//'.

8-)

A ce jour, la définition des accès se fait via le config_local.inc.php...
Imaginez qu'un autre site lance un include de votre config_local.inc.php,
Il obtient les clés d'interrogation prétendument confidentielles pour interroger votre site via services web.
Il n'a plus qu'à lancer les requêtes...

Donc, la gestion des droits va passer dans une table.
Et la gestion de cette table dans l'admin.
Voila pourquoi service web sera livré sous forme d'un MOD après les Releases Candidates de la 1.6.

très bonnes nouvelles !
merci !