Home

Étiquette : réflexion

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

Nouvelles armoiries de communes Neuchâteloises

Armoiries de nouvelles ou ex-nouvelles communes neuchâteloises

L'ère du temps est à la fusion de communes.

Il y a plein de nouveaux blasons, armoiries et noms de communes qui sont proposés.

Mais parfois, il est rare de trouver l'image du blason en bonne qualités.

C'est ainsi que j'ai refaits quelques blasons moi-même pour les utiliser. Ce sont donc des réinterprétations personnelles de ces armoiries, ce n'est pas le dessin original officiel. Mais il est très proche et c'est très utile pour faire des affiches pour les campagnes de fusion.

Pontareuse

Voici les armoiries de l'ex-future commune de Pontareuse.

Les habitants de Bevaix et Cortaillod ayant refusé de fusionner avec ceux de Boudry, (le 15 mai 2011) cette nouvelle commune ne verra jamais le jour.

armoiries de pontareuse.png

Pour jouer avec, voici le fichier en vectoriel au format svg:

armoiries de pontareuse.svg

Milvignes

Depuis le 17 mai 2011, soit deux jours après le refus de la fusion de Pontareuse. Le nom de la peut-être future commune regroupant Auvernier, Bôle, et Colombier est dévoilé, ainsi que ses armoiries.

Voici donc les armoiries de la commune des Milvignes.

armoiries de milvignes.png

Pour jouer avec, et réutiliser les armoiries pour faire la campagne de la fusion, voici le fichiers avec les armoiries de Milvignes au format vectoriel svg:

armoiries de milvignes.svg

Idées et réflexion sur le futur de l’informatique

Réflexions et piste pour l'informatique du futur

Quelques idées

  • Mettre toutes les données sur des accès en réseau.
  • ne garder localement que peu de donnée, car la liaison réseau est excellente.
  • partager les données avec des communautés pour que celles-ci s'améliorent.
  • le ordinateurs doivent devenir invisible.
  • ce que l'on entend actuellement par ordinateur doit se rapprocher de plus en plus d'une interface de commande universelle.
  • contextualiser les services et la recherche et découverte de ceux ci. Dans le genre, je suis dans une pièce, et je les service disponible de cette pièce se montrent par eux même, mais pas les autre qui sont trop loin, donc inutiles. (ex: allumer les lampes, pilotage de la télévision, enclenchement des appareil ménager...)
  • le papier électronique est une étape primordiale de l'évolution de l'informatique vers ce modèle.
  • actullement on a souvent toutes les données, les fonctions, et les applications sur une même machine. Ce n'est pas le bon modèle. Il faut avoir plein de petit appareils facile à utiliser mais qui communiquent super bien entre eux.

Appereil intéressant les simputer indiens. Ce sont des minis ordinateur pas cher (~frs 300.-), conçu pour que tout le monde ait accès à l'informatique.
site d'un constructeur

loisirs

La technologie est de plus en plus orientée loisir ! Musique, film, jeux ...

Mais encore faudrait il avoir le temps d'en profiter... donc plus on a de loisir, plus ça va aller bien pour cette industrie!

ère industrielle / ère de l'information

Dans une société industrielle, basée sur l'énergie, chaque objet est unique. Le principe est la consommation. Plus on possède d'objets mieux c'est. Vu que chaque objet est unique, il est possible de le vendre suivant le principe de l'offre et de la demande. Le capitalisme est basé sur ce principe. Le capitalisme à besoin d'une société industrielle pour bien fonctionner.

Notre société était industrielle, maintenant elle se désindustrialise. Les trois quarts des entreprises suisses travaille dans le domaine terciaire. Le domaine des services. Notre société consomme toujours mais elle ne produit plus.

Nous vivons dans la société de l'information. Tous les grands domaines de notre économie sont basés sur l'information. L'argent même n'est qu'une information. Les banques stockent et gère des flux financiers qui ne sont que des flux d'informations. Les entreprises suisses sont principalement des entreprises qui font un travail de traitement, de tri ou de création de l'information. Tellement il y a d'information, on fait appel à des conseillers pour la trier la synthétiser. Ces services se paient à prix d'or. Mais l'or de cette expression n'est plus là. On en a plus besoin.

Seulement, voilà, le modèle d'économie capitaliste est toujours celui de l'ère industrielle et il n'est plus adapté. Dans une société de l'unique, de l'objet, on définit le principe de propriété. Un individu unique possède un objet unique. Sur ce principe la valeur, ou plutôt le prix d'échange d'un objet se base sur une relation entre entre le nombre d'individu unique désirant posséder un objet unique. C'est le principe de l'offre et la demande.

Papier électronique

Le papier électronique va surtout être avantageux pour personnaliser des surfaces d'affichage à moindre coût énergétique.

Le papier électronique ne consomme de l'énergie que pour changer son affichage. Donc si il ne bouge pas, il ne consomme rien. De plus on peut étendre ce concept et ajouter une couche transparent sur le papier qui est une cellule photo-voltaïque. Ainsi, tant que le papier est a la lumière, il peut fournir sa propre énergie. Vu qu'en général, il faut de la lumière pour lire, et bien le papier électronique sera toujours à la lumière lors de son utilisation.

On peut tout de même imaginer un accu de secours qui est rechargé lorsque il y a surplus de lumière. Celui ci pourrait servir à alimenter une interface de communication avec le monde extérieur (genre bluetooth), ou encore une lampe d'appoint lorsque la nuit est tombée.

Univers 3d :: second life

A l'occasion de la nouvelle année 2007 Fred Cavazza s'essaye à faire des prédictions.

Suite à ces prédictions, une discussion commence à tous sujets et une a particulièrement retenue mon attention. Fred cavazza pense que Second Life va disparaître à cause du spam et à cause de meilleures plateformes comme ce fut le cas avec yahoo et google qui ont supplantés altavista dans le monde des moteur de recherche.

Puis certains renchérissent dans la conversation en arguant que les univers 3d sont lourds pour faire pareil que le web traditionnel, donc il vont disparaître.

Personnellement, cette discussion me fait penser au merveilleux livre de Guy Thuillier: le dixième cercle.

Dans ce roman, de science-fiction, le lecteur est immergé dans un monde fait de gens qui se connectent sur un réseau comme notre internet, mais sous forme 3d et même plus...

Le monde virtuel du réseau est décomposé en 9 cercles, suivant les utilisations qui en sont faite, il y a les premiers cercles, qui sont fait pour la documentation, le pédagogique, puis les applications utilitaires, comme les système de cartographie, les application de bureautique.. et puis, il y a les cercles de jeux, les cercles réservé au sexe et le 9ème qui est un cercle d'univers virtuel dans lesquels on peu ressentir la douleur... le 10ème cercle qui est le titre du roman est le cercle en cours de conception, une technologie qui permet de faire une immersion totale dans un univers virtuel en permettant une dilatation temporelle, faire que toute une vie en monde virtuel ne représente que quelques heure en monde réel.

Je remarque donc que de plus en plus, ces différents cercle commencent à émerger de notre internet. Le cercle pédagogique c'est wikipedia, le cercle applicatif, c'est google, le cercle de chat, ce sont des plateforme comme msn, aim, etc..

Second life est donc la construction du cercle suivant, un univers 3d qui n'exclut pas les autres, mais qui les complètes pour des activités impossible à faire dans une conception web du contenu et de l'interaction.

Les gens qui disent qu'un univers virtuel ne va pas durer par ce que l'on fait des activités identiques avec des technologies plus simple, n'ont pas complètement tort, mais c'est une vision limitée. C'est une vision qui n'est qu'adapter les applications actuelles à un univers virtuel. Mais c'est sans compter les nouvelle applications que la plateforme est seule à pouvoir fournir.

Ce qui me trouble principalement en arrivant sur second life, c'est que l'on est pas seul. En débarquant sur un site web, on ne sais jamais combien d'autres visiteurs sont là, ce qu'ils font.. ou alors c'est sous forme de texte... Le web n'est et ne restera qu'un format de document. Il n'est pas conçu pour l'interactivité.

La messagerie instantanée est souvent appréciée et utilisée uniquement pour avoir un lien avec ses amis. Il y a nombre de personne avec qui je ne parle quasiment jamais, mais je sais qu'ils sont là ! Qu'ils vivent, il y a un petit avatar qui décrit leur humeur du moment.

Le site web, est assez impersonnel, second life, ne présente quasiment aucune activité intéressante, mais il y a un moyen d'avoir un lien avec ses amis, de savoir ce qu'il font. Actuellement, c'est même la seule activité de second life.. c'est se balader entre ami. C'est la nouvelle version du chat irc.

L'univers 3d est un des moyens d'arriver à faire ressentir ce liens de communauté. Dans toute application web2.0 il y a la notion de communauté. Donc je pense que l'interface 3d a un avenir.

Une autre approche, c'est celle qui est proposée par le projet One Laptop Per Child, l'interface utilisateur de cet ordinateur est conçue pour être entièrement collaborative. Il y a moyen de savoir a tout moment ce que font les autres dans les environs.

Certains vont certainement crier au scandale en invoquant le droit à la vie privée, à la protection des données, etc... mais je trouve que dans ce domaine, il y a de l'abus. Pourquoi devrions nous toujours cacher le plus possible ce que l'on fait aux autres c'est par ce que l'on fait des choses pas bien tout le temps Et que l'on tient à son image ??

La plupart du temps, la plupart des gens ne font que des choses qui sont tout à fait honorable ou qui présente un caractère d'une banalité déconcertante.

Tout est question de responsabilité. Si l'on sais que l'on est surveillé. On aura plus tendance à donner une bonne image de soi. Tout le monde à envie que l'on ai une bonne image de sa personne.

Avec une surveillance, (toute relative, une simple présence suffit), je suis certain que la réputation et la responsabilité deviendront de plus en plus importante. Et de part ce fait, le vandalisme et le spam vont diminuer, ceci pour éviter d'avoir l'étiquette de vandale collé à la peau de son identité numérique.

Futur du web

Tristan Nitot sort ça boule de cristal et tente de prédire l'avenir du web.

Voici ce que j'en pense.

Originellement le web a été conçu pour afficher du texte, des documents. Actuellement, le web devient de plus en plus une plateforme applicative. Les sites web statiques deviennent rare.

On peut résumer par: le web 1.0 est une plateforme de document, le web 2.0 est une plateforme d'application.... et le web 3.0 ??

Le web n'est finalement qu'une plateforme qui est souple. Elle s'est adaptée aux besoins. C'est sur internet la plateforme la plus souple, et par conséquent la plus populaire. Pour l'avenir, suivant la loi de l'évolution, soit elle continue à s'adapter aux besoins... soit elle n'occupe plus le devant de la scène et laisse la place à une autre plateforme. (sans forcément disparaître)

Ces derniers mois, sur internet, on observe une certaine popularité pour d'autres plateformes que le web. Les messagerie instantanées sont en train de tuer le e-mail. La presse n'arrête pas de parler d'univers en 3D comme SecondLife. Chaque grosse entreprise informatique présente sa nouvelle plateforme d'application riche XUL/XAML/Apollo/Slingshot etc....

Le web va-il résister à tout ça ? Va il devenir juste un moyen d'accéder à d'autres plateformes ?

Finalement le web a été conçu comme une plateforme de présentation de documents, ne devrait on pas l'utiliser seulement pour ça ?

Dans le livre de science fiction: Le Dixième cercle (de Guy Thuillier), l'histoire se passe en 2099, l'équivalent de l'internet s'est encore renforcé, mais toutes les utilisations que l'on peut en faire ont été séparées en différents "cercles" (d'où le titre), les utilisations de services, localisation, domotique, magasins sont dans un cercle. (widget?). Puis, un cercle réservé à l'éducation, tout ce qui est didactique. (wikipédia ?). Ensuite, un cercle réservé à l'info. (blog,web tv, radio ?) Puis un cercle avec tout ce qui est jeux (WOW?), un cercle avec ce qui est du sexe, etc...

Je trouvais intéressant ce découpage, car les utilisations conditionnent souvent les technologies mises en jeu.

Le défi prochain du web est également d'accepter de plus en plus de type de terminaux d'affichage de type et de format différents. Le papier électronique. (technologie e-ink) va révolutionner prochainement le monde de l'affichage numérique, et qui dit affichage numérique dit format et moteur d'affichage. Expérience faite avec mon livrel (iLiad de iRex), les technologies web sont les plus à même de remplir le cahier des charges de l'affichage d'un même document (journal, livre, affiche, flyer, rapport scientifique, etc) sur des tailles complètement différentes.

Le plus important dans tous ça, c'est de faire attention à ce que les technologies et formats utilisés soient toujours ouverts ! C'est ce qui est la force des technologies du web, et j'espère que ça le restera.

Voici une jolie histoire qui décrit le monde et les technologies de 2030.

10 May 2007 : 11:19

Navigation au sein des articles

1 2 3 4 5 6 7
Remonter