Idées pour une plateforme de jeu sur le web

plateforme de jeu sur le web

Dans les jeux web classiques, qu’est ce qui fait leur succès ?

ogame

  • on peut presque tout le temps faire qq chose.
  • on peut jouer 2 minutes par jour comme 12h par jour.
  • grouper les joueurs par alliance.
  • auto-organisation des alliances.

Exolandia

  • principe d’élection qui permet d’impliquer les joueurs dans la direction que prend le jeu.
  • à chaque niveau des objectifs différents.

La ferme à dd

  • il est possible d’inventer des recettes à partir d’aliments de base.
  • application flash jolie… mais aussi un point négatif, car lente et pas d’onglet… donc très linéaire.
  • grand nombre d’objet à échanger.

Grand principe

  • partager
  • accumuler
  • prendre un rôle
  • créer
  • prendre du pouvoir
  • avoir de la reconnaissance

(pyramide de maslow ?)

Architecture répartie

Un moteur de jeu n’est pas tout seul, n’importe qui doit pouvoir mettre en place un serveur de jeu et s’interconnecter avec d’autres qu’il connaît ! Les villages d’exolandia peuvent être autant de serveurs différents. Seule une API de communication est définie. Cette communication se fait via des services web. Des flux rss (pour le mail entre joueur par exemple.) La frontière entre le jeu et le dehors du jeu doit être la plus fine possible. Il ne sert à rien de re-développer tout et n’importe quoi ! Les utilisateurs veulent partager des images… et bien rendre le jeu compatible avec Flickr.

compter sur les joueurs pour faire le jeu

Le plus dur dans un jeu, surtout s’il prend de l’ampleur, c’est de suivre le développement, de réparer les bug et de répondre aux questions des joueurs.

Comme pour un forum, il faut mettre en place des modérateurs et des administrateurs qui font régner l’ordre ! (ou l’anarchie !) Il faut que le jeu s’auto-équilibre pour qu’il soit viable et intéressant.

Le mieux c’est de permettre aux joueurs de créer les règles du monde dans lequel ils veulent vivre. Donc le plus adapté, c’est un genre de Nomic. Mais pour maintenir la cohésion entre les différents serveurs de jeu / mondes, il faut définir quelques règles de base qui sont immuables. Avec une telle approche du jeu, celui-ci peut être radicalement différent d’un monde à l’autre, mais théoriquement un joueur d’un monde doit pouvoir interagir avec un autre monde.

Selon le principe du Nomic, à la base, un monde est régit par très peu de règles, Puis le tout se complexifie. Les règles peuvent aboutir à un monde démocratique ou alors l’opposé, un monde régit par une dictature. Ou alors, c’est un intermédiaire comme une république.

Le plus dur va être de techniquement créer un système qui permet de suivre les règles mise par les joueurs. Pour cela, le mieux c’est de créer un wiki pour indiquer les règles au format texte… et ensuite, les joueurs peuvent faire correspondre les règles avec des droits ou des restrictions dans le jeux.

implémentation

Il faut concevoir le système de façon souple. principalement jouer sur quelques concepts de base comme:

  • les variables. Une variable est un moyen de mémoriser une valeur. Une valeur est soit juste une valeur simple, ou une valeur composée avec une requête.
  • les groupes, permet de faire des structure de donnée complexe comme des listes, des tableaux ou des arbres.
  • les règles, c’est une contrainte imposée à l’écriture ou la modification de donnée.
  • les objectifs… donner une liste de variable et une liste des états souhaités. L’objectif est atteint lorsque toutes les variables sont des les états souhaités.
  • les objets. Ce sont des groupes de type spéciaux qui sont des agrégats de variables.
  • les éléments. Ce sont des éléments comme un article, ou une image qui ont leur propre fichier d’ajout / modification.
  • les personnages / joueurs
  • les niveaux / objectifs (une partie va être commune à tous les joueur et une autre seulement à certain monde.)

Chaque niveau correspond à des objectifs à atteindre.

Mettre à disposition des joueur certains outils. Par exemple:

  • générateur aléatoire de choix.
  • système de vote.
  • horloge.
  • système de création de groupe (associations)
  • système d’attribution de tâche ou droit à des groupes. (un groupe peut être une personne seule.)
  • place de marché, d’échange.
  • un gestionnaire des outils disponibles.
  • espace personnel bloc note.
  • courrier avec d’autres utilisateurs
  • lister les utilisateurs (d’ici et d’ailleurs)
  • importer / ou copier (suivant leur nature) des objets provenant d’autre monde.
  • un système de comparaison entre les joueurs. (les gens adorent faire des comparaisons entre eux. ça crée de l’information)

Chaque joueur doit être capable de proposer des nouveaux objets. Il ne peut peut être pas les posséder, mais d’autres les utiliser. (réfléchir au sujet de la propriété intellectuelle des objets)

Règles immuables et pré-requis d’interopérabilité.

  • un joueur doit pouvoir vivre dans n’importe quel monde.
  • il y a une unité de base qui est commune pour tous. (énergie, information, etc..)
  • des objets doivent pouvoir être reconnu dans tous les mondes. (mais si dans certains monde, ils sont interdit de possession.)
  • le temps est identique.
  • chaque joueur est en droit de proposer des objets.

Unicité ?

Le monde industriel, énergétique, commerçant, est basé sur le principe de l’unicité. Tout est personnalisé dans cette société, tout est unique et pour cela on fiche les gens, on donne une identité, un numéro.

Faut il faire de même dans la conception de base d’une plateforme de jeu ? Est ce que chaque joueur doit être unique ?

Comment fait on avec les système de vote ? Qui ou quoi à le droit de vote ?

Le droit de vote dépend encore des règles en vigeur. Mais dans la mesure où l’on part du principe qu’un joueur est une entité unique. (on se fiche de savoir si c’est un multicompte ou pas.) Il faut rendre le vote unique. Pour ce faire il faut prendre le contexte du joueur, du vote concerné, et du calendrier. On passe tout ceci à la moulinette md5 et ainsi on obtient un moyen sûr de vérifier que le vote et unique.

Paradigmes principaux à implémenter

  • Les variables
  • Les groupes (avec héritage d’une propriété)
  • Les états
  • Les règles

C’est un peu les concepts minimaux dont il faut disposer pour faire un jeu de Nomic, donc les concepts principaux pour faire le moteur de n’importe quel jeu. (Hormis peut être la partie graphisme)

En fait ces principes sont également très semblables à ce que l’on trouve dans une base de données. Les données, les triggers, les contraintes d’intégrité !

Les variables

Les variables servent à mémoriser une information. C’est l’unité de base de stockage d’information. (bien qu’elle soit remplie d’unité d’information plus petites.)

Les groupes

Les groupent permettent de faire des associations entre des objets. Les groupes permettent de composer des objets complexes à partir de variables. Les groupent via la propriété d’héritage permettent de propager des informations à tout un groupe. Par exemple, voir le système de gestion des permissions de ce wiki.

Les états

Les états sont des états (!) précis de variables. Pour un jeu, un état peut être utilisé comme objectif, comme but. Un état est une généralisation d’un objectif, car un objectif est toujours une entité atomique, l’objectif est atteint ou non. L’état comporte des nuances. Un objectif a toujours une connotation positive, alors qu’un état peu aussi représenter une étape plus négative.

L’utilisation la plus courante va être de définir un état et de tester si l’état est vrai ou non. Donc si l’objectif est atteint ou non.

Les règles

Les règles sont des contraintes que l’on applique aux données. Les règles peuvent être des liens entre des variables et des états. Lors de chaque accès à une variable les règles sont vérifiées.

Il y a deux sortes de règles.

  • les règles qui gèrent l’accès aux variables. Ex: A est accessible seulement si a+b > 3
  • Les règles qui mettent à jour les variables après une modification. Ex: A = b + 2.. donc si je modifie b, va modifier A.

Ces deux sortent sont un peu des contraintes et des trigger ou écouteur.

Question pratique sur l’implémentation

Règles

Sous quelle forme stocker une règle ? Concrètement une règle c’est quoi ?

Dans un firewall, on rencontre des règles, pour ce genre d’activité c’est presque un langage verbeux qui est utilisé. Ci-dessus j’ai montré un exemple de règle avec un langage mathématique. Bref, que faire ? Pour éviter de se limiter, c’est presque d’un langage généraliste que l’on a besoin. Un langage dit de turing.

Une règle est, en fait, un bout de code. Dans un premier temps, la manière la plus simple que je vois de faire une règle est un bout de code php.

Puis, on remarque tout de même une certaine systématique dans les besoin. Cela reflète les opérateurs de base de tout langage de programmation. Il faut des accès en lecture écriture à des variables, il faut des opérateurs de comparaison. (=,>,<, !=), et des opérateurs de calcul (+-*/).

Si l’on prend en compte le définition de règles au sens large, une règle est souvent aussi la vérification d’un état. Une règle peut donc également être composée d’état.

En fait, l’état est peut être même plutôt un sous élément d’une règle, qui n’est pas forcément accessible à l’utilisateur final. C’est en fait l’état qui teste si des variables sont dans certains états prédéfini. La règle ne fait que de lier différents état. Pour lors de certaine action. Un règle est forcément liée à une action.

Comment traduire une règle du genre: Les règles du jeu sont définies par le conseil. ??

Dans cette règles, il faut identifier les acteurs et les actions. Nous avons le conseil comme acteur de l’action définir des règles. Cette phrase est en fait un peu trompeuse, car elle sous-entend que le conseil est formé de gens, mais sans le dire.

La règles va donc être une suite d’opération qui est attachée à l’action définir des règles. Dans cette suite on va tester si l’état utilisateur est dans le groupe conseil est vrai.

Donc pour s’exécuter, une action doit toujours vérifier que toutes les règles qui y sont attachées retournent vrai. C’est comme dans n’importe quel langage de programmation, il y a des procédures et il y a des fonction. La fonction retourne une valeur et la procédure exécuter une série de tâches, mais sans forcément retourner une valeur.

Dans notre cas, la règle va toujours retourner une valeur. Soit vrai soit faux. Pour qu’une action s’effectue, il faut que toutes les règles retournent vrai. Donc une règle procédure, va juste retourner vrai une fois qu’elle a finit son travail.

Il y a deux sortes de règles. Celles qui sont vérifiées avant l’action et celles qui sont vérifiées après. Une règle qui est vérifiée avant l’action. La plupart des règles sont vérifiées avant, car elle servent à la protection des données. Mais parfois, une règle définit ce qu’il faut faire suite à une action. Il est donc utile d’exécuter des règles après une action.

Quelques exemple, pour voir comment interpréter une règle.

  • la règle: Les membres du conseil jouent chacun leur tour
  • les acteurs sont les membres du conseil, il y a également une variable tour qui est un jeton unique. un joueur à la fois peut l’avoir.
  • L’action liée est jouer. Jouer est une synonyme de proposer d’ajouter, supprimer ou modifier une règle.

Dans ce cas, la règle reformulée est du genre, pour propser d’ajouter, supprimer ou modifier une règle, l’utilisateur doit faire partie du groupe conseil et doit disposer d’un objet jeton unique dans le jeu.

  • la règle: Chaque fois qu’un membre du conseil arrive à faire passer une nouvelle règle il reçoit 10 points pour sa patrouille.
  • les acteurs sont: le membre du conseil qui propose une règle. Une variable point à augmenter de 10.
  • l’action est ajout d’une nouvelle règle et la règle en elle même est a effectuer après l’action.

Dans la base de donnée, la table règle comporte:

  • un id
  • un nom
  • un descriptif, qui est la version écrite de la règle.
  • date_creation
  • date_modification
  • le type de la règle: à évaluer avant ou après l’action
  • l’id de l’action à laquelle la règle est attachée.
  • un numéro servant à peut être éventuellement faire un ordonnancement des règles.
  • le nom de la fonction php qui correspond à la règles. (la fonction php est le moyen le plus simple pour réaliser l’implémentation d’une règle. Plus tard, je trouverai le moyen de réaliser ceci avec une interface graphique)
piste pour créer l’interface graphique….

une règle, est vrai si (condition 1) and (condition 2) and (condition 3) etc… ça c’est valable pour une règle qui tend à contrôler l’accès à des donnée. Pour une règle qui tend à mettre à jour des données après l’action c’est pas top…

Implémentation sans base de donnée.

Il est possible de faire une implémentation simplifiée sans base de donnée de ce système. Pour une jeu du nomic, il est clair que le but est de faire les règles, donc forcément il faut un système où il est possible de modifier les règles facilement et en toute sécurité pour le système.

Dans le cas où ce principe de règles est juste utilisée pour réaliser une gestion moins anarchique des accès à des actions, il est possible de placer les règles en dur dans la code.

Chaque action critique dans le code va être répertoriée. Avant de s’exécuter elle va demander à une classe gestionnaire si elle à le droit d’effectuer l’action ou non.

$gestionnaire = new gestionnaireAcces();
$gestionnaire->getDroit(); // effectue l’action si obtient true ou pas reçoit false

un état

Un état c’est quoi ? Plus haut on avait dit qu’un état est la valeur instantanée d’un certain nombre de variable. Puis il y a aussi ce que l’on appelait un objectif, qui est en d’autres termes une condition. si un objectif est remplis, la condition vaut vrai.

Au vue de la structure d’une règle, la notion de condition est fondamentale. On va donc créer un objet condition puis cet objet sera étendu à une liste de condition ce qui pour finir devient un objectif.

La notion d’état est basée sur le même raisonnement mais à partir de l’état d’une seule variable. (il faudra donc ré écrire le texte décrivant ce qu’est un état)

La notion de liste est faite, comme pour tout le reste avec la notion de groupe. Nous auront donc un groupe de conditions. Ce qui est même suffisant pour décrire une règle d’accès à des donnée. (il manque juste les infos spécifique à la règle.)

Donc, un condition c’est quoi ? Une condition est le résultat d’une comparaison entre deux variables. Il faut donc être capable d’obtenir la valeur d’une variable, puis il faut activer un opérateur de comparaison entre les deux. Les opérateur standard de comparaison sont ET, OU, =, !=, > et <. Ces dernier étant exclusivement utilisés pour des nombres.

Le stockage d’une condition se fait donc dans la table avec les champs suivant:

  • id de la condition
  • nom
  • descriptif
  • date_creation
  • date_modification
  • valeur1
  • valeur2
  • opérateur

Module de vote

Le module de vote est une composante indispensable pour faire une gestion démocratique des règles. Cependant, le vote peut être fait de multiple manière. De plus, il ne faut pas confondre vote et élection.

Le mode de vote le plus utile est le mode, un objet, une réponse: oui ou non.

Le principe est simple. Une action proposer au vote est définie. Celle-ci enregistre la proposition, avec des paramètres comme la date, et la personne qui propose. Puis une seconde action est définie: dépouiller le vote. Cette action clos le vote.

Après le vote, il existe donc une nouvelle variable quelque part qui contient le résultat du vote. Celle-ci peut être utilisée.

Le module en lui même est simple, il propose un minimum d’action. Ensuite ce sont les règles associées aux actions qui vont réglementer le tout. Par exemple associer une règle qui définit que la personne qui veut voter doit faire partie d’un groupe corps électoral et on peut compliquer l’accès pour faire partie de ce groupe.

Dans le cas d’une élection c’est un peu différent. Il faut une étape de plus qui consiste en l’inscription des candidats.

Module cron

Ce module permet de définir des tâches qui sont activées à une date et heure précise. Par exemple, si une règle dit qu’une période de votations dure 2 jours. Il faut faire une règle qui au moment où un objet est proposé enregistre une action qui va clore le scrutin 2 jours après.

Concrètement c’est l’utilisateur cron, qui va tenter d’activer l’action. Il faut faire attention au fait que cron doit avoir le droit d’activer l’action.


Les groupes standards

le groupe possessions

Pour déterminer si un objet est en possession de quelqu’un il faut qu’il y ait une liaison, entre l’objet et la personne. Pour imager un peu la chose on va créer un objet du genre sac qui contient toutes les possessions d’un utilisateur. (On peut aussi revoir le nom au lieu de sac, avoir, armoire, maison, inventaire, besace…). Ceci est utile pour être en possession d’un objet comme un jeton qui est l’implémentation de la règle … à son tour….

Ceci pose la question de l’héritage des propriétés d’un objet. Peut être une liste de fonction, de propriété. Un objet sac n’est peut être qu’un objet disposant de la fonction conteneur. La règle du …à son tour.. à seulement besoin de créer un lien entre les possessions d’un utilisateur et lui même. La règle à donc seulement besoin d’une fonction conteneur.

A voir comment faire pour qu’un objet puisse être dans différents objets, mais que le système puisse toujours les retrouver.

Quelques nouvelles idées

Voici, encore de manière très brouillon par ce que mes idées ne sont pas claires et sortent au fil que les écrit, quelques idées que j’ai eu pour créer des applications web.

Cette approche est en particulier intéressante pour des jeux comme j’ai tenté de décrire le fonctionnement ci-dessus. Cette approche permet aux utilisateurs de créer, sans trop de contraintes des objets, de les échanger et de les stocker sans que les concepteurs de la plateforme sache à l’avance à quoi ressembleront ses objets.

Google a lancé en automne 2007 sont projet OpenSocial qui est dans l’idée très proche. Il comporte une définition normalisée de ce qu’est une personne, propose un moyen de voir l’historique de l’activité de cette personne et surtout propose un service web de persistance basé sur AtomPub et REST.

Service web de stockage

Dans une application web on a toujours besoin de stocker des données. (variable, tableau, etc…). Pendant la durée de vie de l’application, la tendance et de tout faire en programmation objet, on a donc une multitude d’objets et de tableaux qui servent à stocker les données. Puis, pour le stockage à long terme, on utilise une base de donnée. Très fréquemment, on utilise le couple php/mysql.

Cependant, une base de donnée (mysql) n’est pas très pratique pour stocker des données vives. L’architecture des tables doit toujours être prévue à l’avance, ce qui contraint énormément l’application. Elle devient très rigide. Dès qu’il faut faire une modification, il faut ajouter un champ dans la base de donnée, puis modifier les fonctions qui permettent de faire de ajout, modification, suppression. Bref, c’est assez lourd.

Cependant, une base de donnée à aussi ces avantages, elle permet de faire très efficacement des tris de données un critère ou un autre.

Le but ici, est de concevoir un architecture de sauvegarde de données sur le web, avec des objets accessibles simplement de partout.

Type de données

On trouve différents type de données que l’on utilise fréquemment dans les application: int, string, date. Puis des structures de données: tableau, liste, pile, arbre, graphe.

Dans une base de donnée, on stocke des: varchar, text, datetime, int. Avec ces types, on crée des tables, une sorte d’objet.

Le but est de trouver un moyen de fédérer tous ces types de données pour trouver un format commun pour les représenter.

Une structure de donnée que j’apprécie beaucoup, c’est le tableau associatif dans son implémentation en php. C’est une structure très souple. Elle permet d’accepter un nombre illimité et indéfini à la base d’élément. On peut faire facilement des tableaux de tableau pour complexifier la structure de donnée. On peut mélanger les différents type que l’on place dans ces tableaux. On peut stocker ou aller chercher des données par indice ou par association.

De plus, le langage php comporte une multitude de fonction qui permettent de manipuler les données, de les trier, de fusionner les tableaux de séparer les clé des valeurs.

L’idée présentée ici est de stocker dans un format accessible par le web une structure de donnée telle que le tableau associatif php.

Une idée qui me vient est d’utiliser un format xml du genre des plist apple, avec une strcuture du genre clé=>valeur avec un nombre indéfini de ces clé. Cette structure est très proche de la structure du tableau php associatif.

Dans OpenSocial, google propose d’utiliser AtomPub comme format d’échange et donc de n’utiliser que des champs standard d’Atom pour représenter la structure de donnée clé=>valeur.

Ainsi, c’est le champs Atome:title qui est utilisé comme clé et le champs Atom:content qui est utilisé comme valeur. Ces 2 champs sont des enfants direct de Atom:entry. Il est possible de mettre un nombre d’entrée (entry) illimité. Donc, ainsi on a réalisé notre tableau associatif. De plus, dans un format atom, il y a une foule de méta données qui sont également envoyé sur l’identité de la source et les dates de création/modification de chaque entrée. Ce qui est très utile pour gérer les conflits de mise à jour d’une application qui utiliserait ces données.

structure REST

Le web est conçu de manière très pratique. La révolution du web est surtout due à la possibilité de pouvoir accéder facilement a des documents aux 4 coins du monde qui sont sur des serveurs différents fourni par des machines différentes. Le web c’est donc, des URL, des adresses qui permettent d’accéder universellement à des ressources, des documents html qui décrivent des ressources document et qui permettent de lier des autres ressources. Ainsi que le protocole http qui permet de transférer les pages.

Il est donc facile sur le web de stocker des pages web (logique!) donc des documents, aussi des images, et quelques formats média (plus compliqué). Il existe aussi toutes sortes de fichiers pour faire de la mise en page et des scripts en tout genres.

Le web est utilisé principalement pour aller chercher des données statiques dans un système de fichier. Mais il peut faire plus. Hormis les requêtes GET Http est également conçu pour faire des requêtes POST, PUT, DELETE, et certainement un foule d’autre pour autant qu’on les définisse.

Le but est donc de pouvoir faire du stockage d’éléments créé dynamiquement et de les poser à l’autre bout du monde avec la simple utilisation d’une url.

Ex: je veux stocker un tableau php que j’utilise dans mon application. Hop, je le sérialise sous une forme xml clé=>valeur, je stocke tout ceci dans une base de donnée, dans une table qui s’occupe de la gestion des méta-données.

Quand je veux le récupérer mon tableau, j’appelle une url particulière avec l’id de mon objet, il ressort sous forme de description xml. Avec simpleXML, en php, il est très facile de recréer mon tableau associatif à partir des données xml.

Système de fichier web

Le système d’url est calqué sur la forme du système de fichier des ordinateur unix. C’est une arborescence. Cette arborescence est étendue en la mélangeant avec des noms de domaines, mais reste une arborescence.

Actuellement, de plus en plus on observe l’émergence de système de classement de donnée par mots-clés plutôt que par arborescence. L’idée est donc ici de créer un véritable système de fichier web basé sur l’utilisation de mots-clés.

Un mot de plus à ajouter au vocabulaire http, pourrait être TAG. Il devient ainsi possible de faire une requête sur une url avec des mots-clés et d’obtenir tous les éléments qui correspondent à la requête. C’est un moyen de retrouver l’efficacité de la recherche que l’on a avec une base de donnée. Car en fait, c’est bien la base de donnée que l’on va faire travailler là. J’ai dis plus haut que l’on fait un stockage des données dans une base et que l’on peut y ajouter des méta-données. Les mots-clés font partie de ces méta-données.

En ce qui concerne le tagging. Ce n’est pas encore très clair dans mon esprit. Faut-il forcer à ce que chaque ressource ait la possibilité d’être taggué quand on lui demande via une requête TAG, ou faut il laisser le tagging à un service fait exprès pour ?

L’avantage su service fait sur mesure est que n’importe quelle URL, donc n’importe quelle ressource peut être taggué sans qu’elle soit faite pour ! (va tenter de faire un tag sur une image !)

Ensuite, comme il existe plusieurs moteurs de recherche (malgré le quasi monopole de google), il peut exister plusieurs moteur de tagging de ressource. C’est exactement ce que fait le service del.icio.us. Chaque URL est classée via des mots clé. De plus, cette application utilise la folksonomie pour unifier les catégories de classement entre des milliers d’utilisateurs.

Donc pour retrouver une ressource on va utiliser ce moteur de recherche/tagging.

En ce qui concerne la normalisation du schéma de requête, google a défini quelques normes… peut être peut on s’en inspirer ??

Toute les requêtes commence par ?q=

Attention à l’écriture concurrente de données !! Chez google on résout le problème en utilisant un numéro de version dans l’uri indiqué dans le document atom. Voir les exemples de mise à jour.

<link rel="edit" href="http://example.com/myFeed/1/2/"/>

L’idée est de créer une horloge logique répartie. On pourrait aussi utiliser la date de modification d’un document. Google ne le fait pas pour des raisons que je n’ai pas trop comprise (fonctionne pas avec DELETE).

Bref, tout ça pour dire qu’il faut penser à la concurrence d’écriture des données dans l’implémentation de l’application.

Authentification

L’authentification reste un problème. Il faut penser à prévoir un service d’identification des utilisateurs et de gestion des droits de ceux-ci sur les ressources. Il est donc probable que pour chaque requête, l’utilisateur doivent décliner ses login/motdepasse. Système que l’on peut simplifier, comme dans n’importe quelle application web, avec l’utilisation d’une clé de session. (dans un cookie ou non)

Il semble que des initiatives commence à voir le jour pour normaliser les protocoles d’authentification entre plateforme web. Ainsi OAuth est peut être une piste à creuser. Cette API est par exemple utilisée sur un service pour s’authentifier sur un autre. (ex: récupération de son carnet d’adresse sur gmail pour vérifier si des amis sont présents sur facebook).

Url sémentique

Le but est d’avoir des url compréhensibles. De pouvoir obtenir des infos rien qu’en écrivant des url. De piloter l’application par les url. Tout est accessible en service web. Il est possible de choisir quel format l’on désire utiliser. HTML pour l’affichage humain.. ou Atom pour une machine. Voici donc quelques exemple et idée pour faire une structure valable.

Obtenir un élément

  • http://extremefondue.ch/document/123
  • http://extremefondue.ch/image/123
  • http://extremefondue.ch/objet/123
  • http://extremefondue.ch/utilisateur/123
  • http://extremefondue.ch/evenement/123
  • http://extremefondue.ch/article/123
  • http://extremefondue.ch/news/123
  • http://extremefondue.ch/blog/123

Ajouter un élément (différentes possibilités… choisir la meilleure)

  • http://extremefondue.ch/add/document/
  • http://extremefondue.ch/document/action:add
  • http://extremefondue.ch/document/add
  • http://extremefondue.ch/index.php?page=document&add ….. c’est réellement la structure
  • http://extremefondue.ch/document/?add … le mieux est de séparer la ressource des actions effectuée sur celle-ci.

Modifier un élément (différentes possibilités… choisir la meilleure)

  • http://extremefondue.ch/update/document/123
  • http://extremefondue.ch/document/123/action:update
  • http://extremefondue.ch/document/123/update
  • http://extremefondue.ch/index.php?page=document&add&id=123 ….. c’est réellement la structure
  • http://extremefondue.ch/document/123/?update

.. idem pour delete..

Tagguer un élément (différentes possibilités… choisir la meilleure)

  • http://extremefondue.ch/tag/document/123/toto,vache
  • http://extremefondue.ch/document/123/action:tag/toto,vache
  • http://extremefondue.ch/document/123/tag/toto,vache
  • http://extremefondue.ch/index.php?page=document&action=tag&id=123&tag=toto,vache ….. c’est réellement la structure
  • http://extremefondue.ch/document/123/&tag=toto,vache

Rechercher un élément (différentes possibilités… choisir la meilleure)

  • http://extremefondue.ch/search/document/vache,toto
  • http://extremefondue.ch/document/action:search/toto,vache
  • http://extremefondue.ch/document/search/toto,vache
  • http://extremefondue.ch/index.php?page=document&action=search&tag=toto,vache ….. c’est réellement la structure
  • http://extremefondue.ch/index.php?page=searche&element=document&tag=toto,vache ….. c’est réellement la structure
  • http://extremefondue.ch/document/tag/toto,vache …ici à nouveau on désigne une ressource par l’intermédiaire d’une recherche

Dans ce cas, il faut choisir si l’on veut une liste de ressources ou directement les ressources elles-même !!! On peut donc faire 2 requêtes différentes.

  • http://extremefondue.ch/document/tag/toto,vache … retourne toute les ressources qui correspondent
  • http://extremefondue.ch/document/taglist/toto,vache .. retourne la liste des ressources qui correspondent

Il est aussi possible de représenter cette recherche en séparant les mots-clés par des /

  • http://extremefondue.ch/document/tag/toto/vache … retourne toute les ressources qui correspondent
  • http://extremefondue.ch/document/taglist/toto/vache/dromadaire qui ne manque pas d’air/ .. retourne la liste des ressources qui correspondent

La solution est donc bel et bien de séparer la désignation de la ressource grâce à une url propre, et l’action que l’on veut faire sur la ressource. Une pure application REST fonctionne par le protocole HTTP. Les actions ne sont pas dans l’url. Les actions sont directement dans la requête http. Ici, pour des raisons de commodité des outils utilisés, on fourni les actions par le mécanisme des paramètres.

URL humaines..

Dans le cas décrit ci-dessus, une ressource est localisée à une url, puis elle est un type d’élément et possède un id. Ce qui identifie très bien et de manière unique toutes les ressources. Cependant, ce n’est pas très pratique pour un humain de se souvenir de l’adresse ou plutôt de différentier l’article 23 et le 27…… un nom est plus humain.

Dans cette structure, tous les éléments ont des métadonnées obligatoire qui sont le nom, la date de création et la date de modification. Il est donc possible de combiner ces informations pour faire une adresse humaine.

Ainsi, une adresse de base suffisante pour désigner une ressource peut être complétée pour indiquer à un humain de quoi il n’agit et proposer une extension de fichier qui peut être utile pour certaine applications.

  • http://extremefondue.ch/document/123
  • http://extremefondue.ch/document/123/balade dans la nature.html

Vue que ce qui est dérrière l’id n’as pas d’importance, on peut y mettre n’importe quoi et être certain que les accents et espace ne gênes pas ! Mais comme ça peut être déroutant… il est possible de faire une version sans espaces.

  • http://extremefondue.ch/document/123/balade-dans-la-nature.html

Communication entre machines

Ensuite, il est possible à des humains d’avoir des ressources. Cependant, pour des machines c’est plus compliqué. L’HTML n’est pas un format facile à comprendre. il faut prévoir plusieurs vues possibles de la même ressources.

Nous avons donc:

  • la vue html qui est la vue standard
  • la vue Atom qui est celle compréhensible par les agrégateurs de flux et plus généralement par les machines.
  • la vue JSON qui est directement interprétable par une application javascript.
  • des formats spécifiques à la ressource tel que vcard, vcalendar,

Ces différente vue sont obtenues en passant en paramètre l’option &output=atom … par exemple.

AtomPub

Hormis la machinerie web pour manipuler des ressources, il est possible de définir un protocole externe pour que des machines puisses manipuler des ressources. Il est ainsi possible de faire des logiciels de bureau et des services web pour manipuler des données.

De nombreux essais sur des plateforme de blog on fait évoluer l’idée pour arriver jusqu’au protocole AtomPub.

voir l’idée avec AtomAPI

Utiliser Atom comme format, et faire un vrai services REST avec les requêtes HTTP GET, POST, PUT, DELETE pour manipuler les ressources. Voilà en gros l’idée.

Ensuite, il faut voir comment implémenter la machinerie, et voir s’il est possible faire cohabiter des interfaces web et un services atompub sur les mêmes url !

En mélangeant encore un peu d’ajax, le tout devient très intéressant.

Jquery supporte les requêtes ajax HTTP put et delete, mais pas dans tous les navigateurs (lesquels?)

Authentification

Il peut être utile de pouvoir restreindre l’accès à certaines ressources. Donc il faut un moyen d’authentifier des utilisateurs. Comment faire avec des ressources accessible via AtomPub ?

Voici un article à ce propos:

http://www.xml.com/pub/a/2003/12/17/dive.html

L’idée est d’utiliser un système d’authentification décrit ici: http://www.oasis-open.org/committees/wss/documents/WSS-Username-02-0223-merged.pdf

…… après de nombreuses réflexion est de nombreux remaniement… voir l’étude concrète de la création d’une application presque REST.. smile clin

7 Mar 2008 : 18:09

Plateforme de prêt de matériel

Réflexions à propos d’une plateforme de prêt d’objets, de matériel

La plateforme est faites !! youhouhou… (24 juillet 2011… après avoir ouvert cette page le 27 juillet 2010 !!)

Allez voir sur yopyop.ch

….. et au vue de manque de succès… et du fait que ce genre de plateforme à fleuri… (donc objectif atteint)… en novembre 2013 j’ai recyclé le nom de domaine pour y mettre mon nouveau site d’expérimentation culinaire…. de la cuisine amusante ! 🙂

Pour partager des objets allez voir la plateforme: http://e-syrent.ch

Ou le projet de partage entre voisins: http://www.pumpipumpe.ch

L’approche de ce dernier est totalement différente de la mienne… avec ma déformation professionnelle de développeur web, j’ai construit une plateforme web pour partager des objets. Du coup, j’ai aussi eu des demandes farfelues du monde entier…..  quand le transport coûte plus cher que l’achat direct !!
J’ai remarqué que finalement ce qu’il faut pour qu’une telle plateforme d’échange fonctionne, c’est la confiance… il faut d’abord prêter à ses amis et à ses voisins.. et ensuite on peut élargir si ça fonctionne… là j’étais parti un peu trop large au début. Le projet d’autocollant de pumpipumpe est très simple.. il n’est pas parfait, mais tellement simple qu’il marche !

Idée de base

Moins de bien, plus de liens !

Nous sommes envahi de plein d’objets que nous n’utilisons que rarement.

Tout le monde à chez soi, un bâteau gonflable, un four à raclette, une tente, un déguisment de pirate, un hamac, des chaises pliante, une machine à coudre, cane à pêche, train électrique, légos, livre, etc….

L’idée est de mettre en commun tous ces objets que finalement nous n’utilisons pas très souvent, mais qui nous encombrent.

Relocaliser l’économie

Si tout le monde dans son quartier agit de la même manière, il sera possible d’optimiser l’utilisation de tout ces objets pour ne plus devoir tout posséder à triple ou quadruple… par la même occasion, c’est une manière de créer des liens avec son voisinage.

En effet, cette démarche doit se jouer le plus possible de manière locale. ça ne sert à rien de faire de nombreux kilomètres de transport pour aller chercher un tout petit objet que l’on rendra une heure après..

Il existe déjà des plateformes d’enchère, comme ricardo ou e-bay. Mais l’idées ici n’est pas pareille. Le but n’est pas de vendre des objets, le but est de les partager.

Il y a derrière cette idée également la volonté de ne pas faire une plateforme de location, mais bien une plateforme de partage.

(contrairement au site http://fr.zilok.com … mais qui fait finalement la même chose ! )

Monnaie locale

Pour avoir un petit aspect viral ethnocentriste, l’idée est également d’introduire une monnaie complémentaire propre à la plateforme. Les « locations » vont se payer dans cette nouvelle monnaie. Le but de ceci est d’inciter les participants à partager eux même leur bien. En partagant, il seront payé et pourront profiter du matériel des autres. En ne partageant rien, ils ne pourront pas gagner d’argent.

Il y a donc aussi une volonté dans ce projet de montrer la force des monnaies complémentaires. Il y a la volonté d’expérimenter également le concept de revenu de vie. L’économie touchée par cette plateforme est trop petite pour pouvoir vivre de ceci, mais elle va permettre tout de même d’expérimenter ce qu’il se passe si on donne arbitrairement de l’argent à tout le monde. Comme au monopoly, à chaque passage au start, tu reçoit une prime ! L’idée est ici de donner une prime à ceux qui jouent. Donc à ceux qui sont présents régulièrement sur la plateforme…. enfin voilà quelques idées de base, maintenant il faudra réfléchir et expérimenter tout ça.

Le nom

Pour la monnaie, le kong. C’est une monnaie de singe ! 😛

Pour la plateforme, il faut trouver un nom qui claque… kitang, koudou… kong.. tient.. les k !! 😛

oubou… toubou… (peuple du niger)

Vu qu’il y a tout un bric à brac on peu imagniner un truc du genre Brikbrak ..bricbrac brikabrak bricabra.ch BrikBrak

Les animaux, c’est toujours pratique pour illustrer…

http://www.heartlandsteaks.com/beef-chart.php

Le boeuf que l’on partage…. 😛 .. ouais mais non…

Beef Chart

Quelques idées en vrac

  • utiliser facebook connect pour identifier les gens
  • utiliser like facebook pour les descriptions des objets

Vu ailleurs..

Le modèle de voiture partagée, «Mobility», est l’embryon de ce qu’on appelle l’économie de fonctionnalité ou de contribution, dans laquelle s’échangent des droits d’usage plutôt que des biens matériels. Anne-Catherine Menétrey dans Le Temps le 22 février 2011

Fonctionnement

Une personne qui arrive sur le site peut s’identifier. Si elle n’en as pas, son compte peut être pré-rempli grâce à facebook connect.

Puis, elle va chercher l’objet qu’elle désire emprunter. Il y a un mini moteur de recherche.

La description de l’objet arrive, il y a possibilité de voir le calendrier des ses réservations.

Puis, il y a moyen de remplir le formulaire de réservation de l’objet. Si aucun conflit de date n’est remarqué, le système crée une réservation en attente. Le propriétaire de l’objet est notifié (flux atom et mail voir facebook) qu’une demande d’emprunt est pendante. Il reçoit dans le même mail, les coordonnées du locataire.

Le propriétaire doit donc (dans un délai raisonnable à choisir) contacter le locataire pour convenir avec lui les modalités de location.

Au moment de la confirmation de la réservation, le locataire va recevoir un mail avec un lien sur l’interface de payement pré remplie. Mais c’est lui qui décide de quand il va l’utiliser.

Modèle de BD

Il y a plusieurs elements qui entre en compte:

  • personnes
  • objet
  • calendrier

Qui sont tous reliés entre eux par une :

  • réservation

Pour les payements nous avons besoins de transaction bancaire.

Afin d’accorder une certaine fiabilité au système, il faut faire des évalutations. La table commentaire permet de s’occuper de ça, elle a un champ evaluation. Si il  = 0 c’est un commentaire et sinon c’est une évaluation. (1-5)

Une nouvelle table evaluation a été ajoutée, c’est plus propre.

Les tables personne et calendrier (et événement) sont celles déjà existantes. Il faut ajouter les tables objet, réservation et transactions. La fortune et les méthodes pours l’augmenter ou la diminuer font déjà partie du manager et bd de personne.

Objet

  • id_objet
  • nom
  • description (html ?)
  • url => pour une description complète au besoin
  • id_proprietaire
  • prix (par jour)
  • caution (en cas de casse de l’objet)
  • latitude
  • longitude => pour le lieu de stockage de l’objet
  • lieu (en vrac écrit… permet de passer en mode geocoding)
  • etat (disponible ou plus) 0 => en cours de création, 1=> disponible, 2=> privé
  • id_calendrier (pour chaque objet on lui attribue un calendrier de ses disponibilités)
  • duree_max
  • duree_min (temps min et max des tranches de location en heure)
  • id_image (pour représenter l’objet)

Reservation

  • id_reservation
  • nom
  • type (définitif – pré réservation) 1-2
  • description
  • id_locataire
  • id_objet
  • id_evenement
  • etat (en attente – accepté – refusé ) 0-1-2

Transaction

  • id_transaction
  • nom
  • description
  • id_source
  • id_destinataire
  • montant
  • ip
  • user_agent => pour mieux contextualiser l’historique de la chose…
  • toutes les dates et métadonnées habituelles..

Détail du fonctionnement de la réservation

Il y a 2 cas de figure que l’on veut pouvoir gérer:

  • La réservation à partir d’une personne déjà enregistrée dans le système.
  • La réservation à partir d’une personne qui est inconnue.

SI la personne est iconnue il faut créer un compte directement à la volée. (dans le cas particulier de la maisec, on pas forcément envie de garder les comptes actifs. Donc on ne propose pas l’ajout d’un mot de passe etc…)

Pour éviter le spam, le formulaire de réservation comporte un système de ticket de session à l’image de ce qui se fait avec les commentaires.

http://yopyop.ch/reservation/?new&id_objet=2   (&id_personne=2)

Donc les étapes de réservations sont:

  • obtenir l’id de l’objet. Si aucun id n’est passé.. on ne continue pas ! (permet d’afficher dans la demande de réservation le résumé de l’objet)
  • obtenir l’id de la personne ou la créer si elle n’est pas fournie. (donc si id_personne est vide et que la session indique un inconnu)
  • (envoyer une notification par mail qu’un compte a été créé.)
  • obtenir les infos d’un formulaire
  • Créer un événement dans le calendrier de l’objet pour les dates données.
  • créer une réservation avec toute ces données.
  • envoyer une notification de la réservation au propriétaire de l’objet.

 

Lancement

Une fois le site fini (ce qui n’est pas le cas), il faut le lancer faire de la pub.

On peut utiliser le principe du club fermé pour lancer le service et faire un buzz.

On fourni un accès uniquement à un nombre limité de gens, et les autres peuvent s’inscrire pour obtenir des infos.

Puis, avec les accès, on donne des invitations pour ses amis… Direct ça fait un buzz… 😛  et ça permet de récolter des adresses mail pour faire un spam 😛

 

Design

J’ai beaucoup d’idées.. beaucoup d’exemple de trucs pas mal.. d’exemple d’interface de services qui ont certains besoins similaires.

Maintenant il faut prendre une décision.

J’aime bien des designs comme ceux de :

Dans l’idée il faut faire un mixe de tout ça et encore d’autre choses.

Les idées de bases sont:

  • un fond de texte blanc
  • plein de couleur pour différencier les parties de l’application. Il faut des couleurs dans le genre de la marque roxy. (ski)
  • utiliser une taille de police assez grosse (17px)
  • utiliser une couleur de police un peu grise
  • utiliser la police georgia italique
  • le découpage du site est fait avec des barres de couleur et des bloc de couleur.
  • utiliser la tête du singe comme logo du site. ça popularité est confirmée. 4ème sur ocal ! bientôt 12000 téléchargements
  • utiliser des images à plat comme symbole. Le design global doit être genre à plat. Avec des formes simple. Des archétypes. S’inspirer des panneaux de signalisation de gare.

Sytème monétaire

Pour introduire ce système de prêt d’objet, l’idée est d’y coupler une monnaie complémentaire.

Comme le dit Bernard Lietaer dans ses conférences, quand on crée une monnaie il faut savoir quel est sont but, toutes les monnaies sont différentes.

Ainsi, le but ici de cette monnaie est de favoriser les gens à jouer à ce jeu, à crontribuer au système collabortif.

Il faut donc:

  • rémunérer les gens qui ajoutent des objets sur le marché
  • taxer les gens qui capitalisent (en introduisant une monnaie fondante)
  • tenter de trouver un moyen de convertibilité avec d’autres monnaie. (c’est bien ce qui a fait décoller le bitcoin) Peut être qu’on peut réaliser cette convertibilité via un système du genre c3. Ce système propose une monnaie qui est en fait une assurance sur une facture. Si l’on veut de la monnaie nationale traditionnelle directement, il faut payer un intérêt, si l’on reste dans le système, on peut payer avec cette facture garantie par l’assurance.
  • Il faut indiquer dès le départ que c’est une monnaie dont les règles sont suceptibles de changer, mais que c’est à la communauté de définir ces règles. C’est une monnaie démocratique.
  • Il faut augmenter la masse monétaire.. comment faire ?

Todo

  • les objets vu sur une carte
  • liste des réservations en cours
  • le système monétaire
  • explication du système monétaire
  • changement de l’image des objets
  • introduction de la date de naissance
  • flux atom de notification
  • image de profile autre que gravatar
  • visibilité des objets restreintes à des groupes
  • mail multipart

Fait

  • système de tableau de bord
  • envoie de mail
  • gestion de son compte utilisateur
  • design

Quand faut-il faire une notification ?

  • Création d’un compte à la volée: type (1)
  • si je fais une demande de réservation d’un objet:
    pour moi (2) => Vous avez fais une demande de réservation de l’objet drapeau pirate
    pour le proprio de l’objet (3) => Martouf fais une demande de réservation de l’objet drapeau pirate
  • Si j’accepte une demande:
    pour moi (4) => vous avez accepté la demande de réservation de l’objet Drapeau pirate
    pour le locataire (5)=> Martouf a accepté votre demande de réservation de l’objet Drapeau pirate
  • si je fais un changement dans une réservation:
    pour les deux (6)=> la réservation de l’objet drapeau pirate a été modifiée
  • (7) pour une notification de transaction financière

Les champs createur et modificateur de l’objet notification sont mis à jour automatiquement, c’est l’id de session qui est utilisé. Ainsi on sait toujours qui est à l’origine de l’élément déclencheur d’une notification.

Pour savoir à qui est destiné la notification, on utilise le champ evaluation, dans lequel on place l’id de l’utilisateur concerné. Celui qui doit évaluer ! (c’était plutôt un oubli de ce champ, où plutot je m’étais dit que l’on pouvait faire une relation plusieurs à plusieurs.. mais ce sera plus facile à gérer avec un champ directe dans la table)

Il ne faut pas oublier le champ Etat qui est à 0 par défaut. On place l’etat à 1 si l’info est lue.

Voir pour faire un petit bouton ajax pour dire « info lue.. »