[API] Besoins

[leosw]

Ah oui en effet, j'avais pas du tout pensé à l'export des polygones, est-ce que tu peux m'en dire un peu plus sur les besoins ?

Comme paramètres je pense à

* bbox - La vue en cours
* format - geojson...
* type - cartes, massifs, pays...

Léo

[Dominique]

C'est juste pour la doc.
L'API (ou du moins l'exportation) existe déjà:
http://www.refuges.info/exportations/ma ... at=geojson

[leosw]

Oui mais à terme le dossier exportation va disparaitre je pense, et les requêtes AJAX se feront toutes vers l'unique API, enfin c'était mon but et mon idée.

[Dominique]

Oui, pourquoi pas. Préviens moi car j'utilise ces interfaces pour d'autres raisons (chemineur, vttrack, ...)
Je donnais le lien car le fichier qu'il génère sert de spec

{
type: "Feature",
properties: {
nom: "Aiguilles rouges",
color: "#91009a",
url: "http://www.refuges.info/nav/12/massif/Aiguilles-rouges/",
},
geometry: {
type: "Polygon",
coordinates: [[[6.84,45.909999999999997],[6.91,45.969999999999999],[6.91,46.030000000000001],[7.04,46.130000000000003],[6.98,46.270000000000003],[6.83,46.159999999999997],[6.77,46.149999999999999],[6.71,46.100000000000001],[6.59,46.109999999999999],[6.55,46.07],[6.6,46.049999999999997],[6.66,45.920000000000002],[6.76,45.93],[6.78,45.890000000000001],[6.84,45.909999999999997]]]
}
},

[leosw]

Oui oui,

Dans un premier temps l'API sera un doublon je pense, le temps de la transition.

Il y a une newsletter que j'ai mit en place pour l'API, tu peux t'y inscrire déjà, même si je pense que j'enverrais le liens aux intéressés (toi, vttrack, eosya) plus tard

Pour se faire connaitre : http://leo.refuges.info/api et mettre son mail en haut à droite

[Dominique]

Note: vvtrack est via chemineur (ils n'accèdent pas en direct)

[sly]

J'ai l'impression que tu as bien avancé tes fonctions de l'API mais que nous n'avons pas pris le temps de discuter des appels. Leurs forme, leurs paramètres, l'info renvoyée, etc.

Je sais que causer c'est pénible pour un informaticien (fait chier les réunions !), surtout quand il risque d'y avoir des désaccords. Mais en discuter avant me semble préférable qu'un "c'est de la [censuré] ton truc" une fois que tu as fini après 3 mois de boulot.

Si tu étais l'unique mainteneur de cette API pour les 5 ans à venir, à la limite, j'me dirais qu'on t'ouvre un ticket et tu fais, mais je sens qu'il va bien falloir qu'on fiche notre nez là dedans pour la maintenance sur le long terme, et étant plutôt un extrémiste de la factorisation de code je préférerais commenter voire participer au fûr et à mesure du développement.

Un autre opinion sur l'organisation du développement ?

[Dominique]

Permettez moi de vous donner mon avis (qui n'engage que moi) et, comme je n'ai pour l'instant pas l'intention de participer à sa programmation, vous faites comme vous voulez. C'est aussi celui qui bosse qui a force de proposition (sous réserve d’acceptation de support par les autres).

Si l'on parle d'interface entre h:w.r.i/quelquechose et une autre machine connectée en IP (PC avec explorateur, mobile, autre serveur), je parlerais plutôt de "Web Service" que d'"Application Programming Interface" qui serait "un ensemble normalisé de classes, de méthodes ou de fonctions qui sert de façade par laquelle un logiciel offre des services à d'autres logiciels" (Wikipedia).
Ceci quel que soit le langage utilisé pour cet interface (html, GML, KML, geoJson, ...) que je mets tous au même niveau (aucun n'est un langage naturel et tous nécessitent une interprétation avant d'être présentés à un humain).

Une fois posé ce modèle (simplificateur et donc permettant la factorisation) nous avons, je crois, opté pour un modèle MVC (quelquefois, les informaticiens tombent d'accord ) : exit les "exportations" ou "page point" ou "page forum" ou """API""" : ce sont pour moi autant de vues. Standardisons.
Quand à prendre un modèle MVC, autant en prendre un existant. Et si possible, un logiciel existant et intégrant le contrôle des users... voire les données du forum.
Bon, vous le savez, mon choix est de partir d'un logiciel de forum (pourquoi pas PHPbb mais un autre ferait l'affaire).

J'ai fait un proto de chemineur chemineur.cavailhez.fr sur ce principe où toutes les données de fiches sont saisies et gérées par le forum et affichées par le forum, y compris les pages d'exportation et de flux GML, ... qui passent par le système de templating PHPbb3.
La factorisation est max car:
- quelques dizaines de lignes de modifs au kernel PHPbb3 pour gérer les données géographiques
- quelques templates format PHPbb3 pour les pages, flux, ...
- 2 ou 3 controleurs supplémentaires (par exemple pour les flux de points)

... et pour le même prix (juste l'installer), j'ai même un interface mobile: http://chemineur.cavailhez.fr/?mobile=mobile

[leosw]

Mais en discuter avant me semble préférable qu'un "c'est de la [censuré] ton truc" une fois que tu as fini après 3 mois de boulot.

D'accord pour discussion IRC ou autre selon vos dispos

Si l'on parle d'interface entre h:w.r.i/quelquechose et une autre machine connectée en IP (PC avec explorateur, mobile, autre serveur), je parlerais plutôt de "Web Service" que d'"Application Programming Interface" qui serait "un ensemble normalisé de classes, de méthodes ou de fonctions qui sert de façade par laquelle un logiciel offre des services à d'autres logiciels" (Wikipedia).

Le terme API était pour là car seule des applications vont appeler ce que j'appelle l'API, et j'ai toujours vu API développeurs sur les autres sites, même si cette API est une web API. Mais ont peut changer de terme je n'y vois aucun soucis.

Bon, vous le savez, mon choix est de partir d'un logiciel de forum (pourquoi pas PHPbb mais un autre ferait l'affaire).

Personellement je suis assez tiède sur ce point, pour moi un forum est un forum, avec les fonctionnalitées d'un forum. Pas plus. Le modifier comme tu l'a fait créé un mélange entre-deux.
Si il est question de s'appuyer sur une base, je pense que en effet c'est possible, en conservant un modèle MVC et du PHP. Mais il faut se tourner vers un framework car WRI est nouveau et n'est pas un forum.
https://fr.wikipedia.org/wiki/Mod%C3%A8 ... eur#En_PHP

Je ne connait aucun d'entre eux mais ai vu de nombreux projets sous Symphony, Joomla ou encore Zend...

Léo

[Dominique]

Le terme API était pour là car seule des applications vont appeler ce que j'appelle l'API, et j'ai toujours vu API développeurs sur les autres sites, même si cette API est une web API. Mais ont peut changer de terme je n'y vois aucun soucis.

Les fournisseurs de service (prenons par exemple les fournisseurs de cartes parlent de "Géoservices IGN pour le web".
Ils offrent aussi une API: en général une librairie JS qui permet l'inclusion d'une carte en quelques lignes de code.

[leosw]

Oui dans leur cas c'est un géoservice pour le web, car on ne peut récupérer des tuiles que via un serveur web.

Nous c'est une API, qui peut être utilisée par une application, un site ou une application mobile. C'est aussi une API car elle exporte la base de donnée et permet de communiquer avec celle-ci, comme l'API Facebook, l'API Newsblur sur laquelle je me suis appuyé, l'OverpassAPI pour OpenStreetMap...

[Dominique]

Personellement je suis assez tiède sur ce point, pour moi un forum est un forum, avec les fonctionnalitées d'un forum. Pas plus. Le modifier comme tu l'a fait créé un mélange entre-deux.
Si il est question de s'appuyer sur une base, je pense que en effet c'est possible, en conservant un modèle MVC et du PHP. Mais il faut se tourner vers un framework car WRI est nouveau et n'est pas un forum.
https://fr.wikipedia.org/wiki/Mod%C3%A8 ... eur#En_PHP

Tout à fait d'accord. Je me tâte sur ce point, surtour que le code PHPbb n'est pas un modèle de limpidité ni prévu pour s'interfacer.

Je ne connait aucun d'entre eux mais ai vu de nombreux projets sous Symphony, Joomla ou encore Zend...

Joomla est plutôt un CMS qu'un framework, c'est à dire plus orienté publication (seuls quelques rédacteurs contribuent, avec action de mise en ligne) qu'un WEB 2.0. Sur ce point, WRI est plus un forum qu'un site de publication.
J'ai tenté Zend, mais il faut être passionné par la programmation objet absconse à haut niveau d'abstraction et d'héritage. Perso, j'ai rien pigé . Et puis, je n'ai pas trouvé de module d'identification et là, c'est un truc à absolument prendre tout fait. Par contre, ça a l'air performant pour peu que l'ami SLY l'intègre à son Apache.

Je suis désolé, mais j'en reviens à mon point de départ: WRI EST un forum

[sly]

C'est aussi celui qui bosse qui a force de proposition

Je m'efforce d'adhérer à ce principe.
Là, c'est léo qui semble parti pour faire, ni toi ni moi ne sommes très motivé/disponible pour vraiment coder cette API/web service
avec lui. Je devrais donc le laisser faire comme lui pense qu'il est bon de faire. (Mais j'arrive pas totalement !)

L'avantage d'être 3 développeurs c'est que si un n'est pas d'accord avec les deux autres, on choisi à la majorité et ça avance !


ps: pour le reste de ton message, je n'ai pas trop vu où tu voulais en venir (à part phpBB3) et c'est un peu trop abstrait.
- MVC et factorisation ? on peut très bien respecter le MVC et multiplier le copier/coller
- pas de noms que des vues ? ben oui, mais on peut donner un nom aux vues

[sly]

D'accord pour discussion IRC ou autre selon vos dispos

je serais dispo sur IRC demain vers 18h00 histoire que je te présente ce que j'ai vu de ton API actuelle et le comparer à ce que j'avais en tête.
Mon idée à peu être aussi des défauts et autant qu'on cause un peu avant de foncer !

Pour le reste tout pareil que toi.
phpBB3 : j'y crois pas, mais dom le sait ;-)
API ou web API me va comme appellation et l'appel /api/xxxxx?yyy me va très bien
framework : j'utilise laravel au taf depuis 6 mois et je commence à mieux comprendre plein de concepts récurrents des framework
https://fr.wikipedia.org/wiki/Laravel

(ça ne veut pas dire que je veux passer wri à laravel)

ps pour zend: je connais pas mais s'il faut installer un truc sur le serveur, on fait ce qu'on veut, il est dédié à wri, donc on ne doit pas se laisser bloquer par un outil qui manque.
(ça veut pas dire que j'ai envie d'apprendre zend ;-)

[Dominique]

je serais dispo sur IRC demain vers 18h00 histoire que je te présente ce que j'ai vu de ton API actuelle et le comparer à ce que j'avais en tête.

Pas dispo désolé.
Je m'adapterai à ce qui sera choisi.
Mon seul point serait d'utiliser le même templating et MVC pour les exportations, flux et pages mais bon, si vous voulez faire du code séparé pour chacun, je n'y vois pas d’inconvénient.