z0rglub a écrit:

remarque de compréhension générale : j'ai eu de vraies difficultés à lire ta spécification car tu fais référence à des notions que tu définis plus tard dans le texte. C'est troublant. En relisant ma réponse, on voit clairement qu'il a fallu que je relise la spec en entier pour comprendre le premier paragraphe :-/

Tout à fait, je l'ai retourné déjà dix fois. Et Wiki est en état FIXME.
Pour le reste, je te répondrai (si réel problème uniquement) au cas par cas, demain.
Quoique vu l'heure, ça sera sans doute aujoud'hui.

VDigital a écrit:

z0rglub a écrit:

Pourquoi faire une feuille de style CSS ? [...] Bref, je ne comprends pas :-/

Si je peux éviter de passer via XSL, j'éviterai mais évidement ce n'est pas certain.
CSS et DTD devrait suffire. Je fais des tests.
CSS pourquoi?... Le blog intègre les images a sa sauce. Je veux aller plus loin que de l'affichage d'un peu de texte et de l'image correspondante.

Je ne comprends toujours pas. Un petit exemple m'aiderait je pense. Dans mon esprit, les web service ne servent qu'à donner de l'information. C'est à l'interrogateur du service (un blog, un forum, que sais-je encore) de gérer la présentation des données récupérées via service. Que PWG soit lui même un des clients possibles dans la fonctionnalité avancée d'échange que tu proposes, OK, mais dans le cas de base, il vaudrait mieux se limiter à fournir de la donnée brute.

VDigital a écrit:

[... à propos de la fonctionnalité de communication inter-PWG via service web ...]
Je reconnais que ce n'est pas évident à suivre...

Non, mais maintenant j'ai bien compris je pense.

VDigital a écrit:

"C'est un travail énorme": Non ! Non ! et Non.

Mettre en place un client de service XML, gérer les cas d'erreur, etc. Si, c'est un gros boulot. Surtout qu'il faut déjà que la fonctionnalité de serveur de service web fonctionne avant de faire cette fonctionnalité avancée. Enfin, pour un simple développeur comme moi, cela me semble être un gros boulot pour bien le faire.

VDigital a écrit:

"Je suis presque sûr que ça ne va pas intéresser grand monde", crois-tu?

Subjectivement, je pense que ça va intéresser une très petite minorité des utilisateurs [edit] actuels. Cela ne veut pas dire qu'il ne soit pas intéressant de l'implémenter. Pour rappel, je ne détiens pas la vérité et peut-être que c'est la fonctionnalité que tous les non-utilisateurs de PWG attendent.

VDigital a écrit:

Ta réaction ressemble à un jugement de valeur... Moi je veux l'avis d'un vimages sur ce point par exemple.

Qu'est-ce qu'un jugement de valeur exactement ? Parce que je ne comprends pas ce que tu sous-entends. Attention, ce n'est pas parce que je ne suis pas convaincu à la première lecture que je ne le serai pas à la seconde. Et puis de toute façon, même si j'ai un poids important dans la décision d'intégrer telle ou telle fonctionnalité, on décide à plusieurs. Depuis au moins 1 an, je pense faire suffisamment d'efforts pour faire participer le plus grand nombre aux discussions.

VDigital a écrit:

Cela s'appelle de l'échange? C'est plus fort que de l'échange de banière. Beaucoup plus subtil. Tu ne crois plus au mode libre?

Dans ce cas là, on retire le système de permissions (joke). Bien sûr que je crois à l'échange, c'est d'ailleurs ce qui permet à Flickr de faire fureur. Si je ne croyais pas à l'échange, je ne proposerais pas une fonctionnalité de service web (je rappelle que j'ai écrit le premier post de ce topic quand même).

Mon opinion : sépare la fonctionnalité de communication inter-PWG du reste. Fais-en une spécification à part ayant comme prérequis la fonctionnalité de service web. De cette façon, on y verra tous plus clair et les développements se feront en 2 étapes.

VDigital a écrit:

Ok, mais comprends aussi que si je n'en tiens pas compte au niveau des concepts, nous aurons encore plus de mal à l'implenter dans la phase "ultérieure" (peut être 2ème étape, comme 3 ou 4ème, je n'en sais rien aujourd'hui).
D'où les restrictions, le double niveau de contrôle, etc.

Quel double niveau ?

Avec le recul que j'ai (celui de la personne n'ayant pas écrit la spec), la fonctionnalité de communication inter-PWG, c'est l'intégration d'un client de service web fournit par PWG. Exactement comme je compte en écrire un pour Dotclear. S'il manque des caractéristiques à la première implémentation de la fonctionnalité service web (ce qui sera le cas, obligatoirement), on pourra évidemment en rajouter dans une seconde version de l'implémentation.

Bref, prends en compte la communication inter-PWG pour spécifier la fonctionnalité de service web, sans pour autant la nommer. La communication inter-PWG n'est qu'une des nombreuses possibilités offertes par les services web. (cette fonctionnalité est notée comme stratégique 1.6 dans mon cahier si tu veux tout savoir)

Désolé, mais je ne vois toujours pas l'intérêt de $conf[’XML_service’] (via fichier) + $conf['XML_switch'] (via écran). [Administration>Catégorie>Service web] permettra de créer le strict équivalent à $conf['XML_switch']. Imagines que pour les commentaires utilisateurs, il faille les autoriser dans [Administration>Configuration>Commentaires] puis autoriser les catégories dans [Administration>Catégories>Commentaires]. Ce serait pénible et inutile.

A la limite, en suivant ce raisonnement, $conf[’XML_service’] (via fichier) devient inutile. Sauf que tu estimes qu'il y a des administrateurs qui accèdent à l'interface d'administration de PWG sans pour autant pouvoir accéder au fichier de configuration. Dans ce cas, c'est sensé.

Je trouve quand même dommage d'imaginer qu'il puisse être utile de désactiver le service web parce qu'on confie l'administration de sa galerie à une personne à laquelle on n'a pas confiance :-/ un comble. J'ajoute que ne sachant pas vraiment qui utilise le service, en désactivant, cela aura des conséquences sur un nombre inconnu de sites externes.

C'est simple, je veux éviter qu'un malin se constitue à l'oeil, la galerie des plus belles images des autres galeries, non?

Là, tu soulèves un problème plus profond : finalement, qui a le droit de questionner le service web ? L'idée que j'avais au départ, c'était simplement que tout ce qui était visible de guest, soit accessible via service. Tu proposes de rajouter une condition : que l'image soit associée à au moins une catégorie accessible via service. Maintenant, tu sous-entends qu'il faudrait contrôler qui accède aux photos via service. Je dis attention quand même : ça va devenir vraiment très très galère de gérer des permissions spécifiques au service. Et l'échange alors, tu ne crois plus au mode libre ?

Imaginons une galerie perso, l'admin ne souhaite pas que n'importe qui puisse afficher ses photos perso de manière incontrôlée. Ne devrait-on pas donner la possibilité de ne questionner le service qu'avec une clef ? du type $conf['service_key'] = 'TS9VqM73'; et cette clef ferait parti des paramètres de l'URL de requête au service. Ainsi, je suis sûr que seul mon blog sera capable d'utiliser le service de ma galerie. Il y a peut-être une idée à creuser, non ?

Je serai plutôt en faveur de la possibilité de limiter l'utilisation du service aux personnes à qui j'ai donné la clef. Il faut par ailleurs tenter de simplifier la configuration au nécessaire. C'est pourquoi je suis plutôt contre $conf[’XML_service’] (via fichier) + $conf['XML_switch'] (via écran). Au final, dans le modèle que tu proposes, il y a 3 niveaux de contrôle (en rajoutant la propriété agreed_xml_service de chaque catégorie), et ça fait trop pour des gens comme moi (des gens avec un petit cerveau).

z0rglub a écrit:

Désolé, mais je ne vois toujours pas l'intérêt de $conf[’XML_service’] (via fichier) + $conf['XML_switch'] (via écran).

Ne soit pas désolé. 8-)

z0rglub a écrit:

[Administration>Catégorie>Service web] permettra de créer le strict équivalent à $conf['XML_switch']. Imagines que pour les commentaires utilisateurs, il faille les autoriser dans [Administration>Configuration>Commentaires] puis autoriser les catégories dans [Administration>Catégories>Commentaires]. Ce serait pénible et inutile.

Bonne remarque: Justement, tiens je voudrais autoriser les commentaires, mais avoir une catégorie non comment"able"? Comment fais-je?

z0rglub a écrit:

A la limite, en suivant ce raisonnement, $conf[’XML_service’] (via fichier) devient inutile. Sauf que tu estimes qu'il y a des administrateurs qui accèdent à l'interface d'administration de PWG sans pour autant pouvoir accéder au fichier de configuration. Dans ce cas, c'est sensé.

Quasiment jamais utilisé certes, mais censé et pratique.

z0rglub a écrit:

Je trouve quand même dommage d'imaginer qu'il puisse être utile de désactiver le service web parce qu'on confie l'administration de sa galerie à une personne à laquelle on n'a pas confiance :-/ un comble. J'ajoute que ne sachant pas vraiment qui utilise le service, en désactivant, cela aura des conséquences sur un nombre inconnu de sites externes.

Je sais bien et tu as raison, mais je cherche aussi à nous protéger:
" Ne venez pas vous plaindre, vous aviez le moyen d'éviter l'affichage de ces images sur votre site même en votre absence. Vous êtes responsable de votre site en aucun cas l'équipe de PWG. "

z0rglub a écrit:

C'est simple, je veux éviter qu'un malin se constitue à l'oeil, la galerie des plus belles images des autres galeries, non?

Là, tu soulèves un problème plus profond : finalement, qui a le droit de questionner le service web ? L'idée que j'avais au départ, c'était simplement que tout ce qui était visible de guest, soit accessible via service. Tu proposes de rajouter une condition : que l'image soit associée à au moins une catégorie accessible via service. Maintenant, tu sous-entends qu'il faudrait contrôler qui accède aux photos via service. Je dis attention quand même : ça va devenir vraiment très très galère de gérer des permissions spécifiques au service. Et l'échange alors, tu ne crois plus au mode libre ?

Librement autorisé... (par défaut: Publique toute catégorie autorisée sera), oui, au monde libre, je crois (librement inspiré de maître yo...).

z0rglub a écrit:

Imaginons une galerie perso, l'admin ne souhaite pas que n'importe qui puisse afficher ses photos perso de manière incontrôlée. Ne devrait-on pas donner la possibilité de ne questionner le service qu'avec une clef ? du type $conf['service_key'] = 'TS9VqM73'; et cette clef ferait parti des paramètres de l'URL de requête au service. Ainsi, je suis sûr que seul mon blog sera capable d'utiliser le service de ma galerie. Il y a peut-être une idée à creuser, non ?

Dis-moi la différence en tu as un ticket valable et tu as une clé valable? Ok, on parle de clé, et je ne peux pas ne pas l'intégrer dès la 1.6

z0rglub a écrit:

Je serai plutôt en faveur de la possibilité de limiter l'utilisation du service aux personnes à qui j'ai donné la clef. Il faut par ailleurs tenter de simplifier la configuration au nécessaire. C'est pourquoi je suis plutôt contre $conf[’XML_service’] (via fichier) + $conf['XML_switch'] (via écran). Au final, dans le modèle que tu proposes, il y a 3 niveaux de contrôle (en rajoutant la propriété agreed_xml_service de chaque catégorie), et ça fait trop pour des gens comme moi (des gens avec un petit cerveau).

Je ne marche pas... z0rglub joue au poker menteur. Il a tout compris, il est vrai que c'est compliqué mais on ne peut guère faire autrement.
Pour l'instant, je ne lance pas XML_switch.
Mais pour le reste, 2 phases:
1.6 de PWG:  XML Service avec XML_Service en $Conf, agreed_xml_service au niveau des catégories et un tableau de 'service_key' en $conf.
1.7 ou + (ultérieurement): Les catégories partagées.

VDigital a écrit:

nicolas a écrit:

Excusez-moi de metttre les pieds dans le plat mais quand je vois service je ne peux pas m'empêcher de penser à échange d'information comme l'a souligné Pierrick dans un de ses messages mais surtout je pense à soap ou xml-rpc. A aucun moment je n'ai vu cela. Est-ce volontaire ? Pourquoi vouloir réinventer votre propre protocole ?

Nicolas, merci de ton intervention...
J'ai bien sûr vu ton message et je regarde WebServices - SOAP ou XML-RPC.
ET je ne tiens pas particulièrement à réinventer la roue.
Les as-tu utilisés ???

J'ai déjà utilisé xml-rpc et soap même si j'ai une petite préférence pour soap.

VDigital a écrit:

Crois-tu qu'ils peuvent répondre à des questions très spécifiques?

Oui je pense.

VDigital a écrit:

Voir en liste les types de requêtes susceptibles (Arguments) d'interresser soit un blog soit une autre galerie.

Je n'ai pas regardé en détail tous les services que vous voulez proposer; je regarderais.

L'avantage d'utiliser soap (ce serait la même chose avec xml-rpc) masque toute la problématique service. Tu crées juste des fonctions qui renvoient le résultat attendu. La classe soap se charge du transport.

Je vous -//:---\spam un exemple dès que j'ai un moment et que j'ai terminé avec les sessions.

Apparemment, Flickr propose plusieurs méthode (REST, SOAP, XML-RPC), non seulement pour le format de la réponse, mais aussi pour la question. Voir la Documentation de l'API de Flickr.

Pour savoir quoi choisir comme premier format d'échange, il faudrait peut-être se baser sur l'expérience d'autres applications (Dotclear ? autre ?)

nicolas a écrit:

z0rglub a écrit:

Pour savoir quoi choisir comme premier format d'échange, il faudrait peut-être se baser sur l'expérience d'autres applications (Dotclear ? autre ?)

Je m'en doutais! :-) Dès que tu cherches à faire quelque chose tu regardes comment ça a été fait sur dotclear ?

Ou sur punbb, ou dans mantis (sauf que pour la fonctionnalité dont nous discutons dans ce topic, je pense que seul dotclear est intéressant). En effet, je pense gagner du temps en partant du point d'arrivée des autres.

Attention, je ne fais cela que pour des fonctionnalités très courantes. Pour tout ce qui concerne la gestion des catégories, inutile de chercher ailleurs, PhpWebGallery est fonctionnellement largement plus avancé que la plupart des autres applications (tout type d'application confondu).  J'estime plus intéressant de passer du temps à réfléchir sur la gestion des catégories, la classification, etc. que sur des fonctionnalités déjà présentes partout. Question de point de vue.

nicolas a écrit:

Je n'ai pas la même démarche: je recherche des docs officielles, des protocoles standards, des design patterns,... J'implémente une version minimaliste et fonctionnelle et je regarde comment les autres ont fait. Généralement on arrive aux mêmes résultats.

Alors c'est dommage d'avoir passé du temps à refaire le même boulot que d'autres ont déjà fait :-/ Si ta conclusion avait été "on arrive à un résultat meilleur", je n'aurai pas fait la même remarque :-)