Plus sérieusement, Snippy est un site quelque peu novateur, qui permet de stocker des idées publiques ou privées en les catégorisant à l’aide de #hashtags. Il permet de stocker des scripts, des URLs dont on veut se souvenir avec un commentaire, des recettes de cuisine, l’adresse de quelqu’un, etc.

Ces informations peuvent être catégorisées mais aussi regroupées et retrouvées aisément. En effet, les hashtags placés apparaissent sur le site et on peut donc retrouver ce qui nous intéresse dans la masse d’informations que l’on est amené à stocker. Pas besoin de recherche texte ou de paramétrage complexe, ici c’est l’auto-convention qui est mise en place: si je décide que tous mes post-its sysadmin sont taggés #sysadmin alors je sais comment retrouver une info rapidement.

Les snippets (unités de Snippy) peuvent être édités, mis à jour et, si jamais l’envie de le faire prend leur auteur, effacés.

La force principale de Snippy est que les snippets peuvent être publics. J’espère que cet outil deviendra une base de connaissances variées et consultée par le plus grand  nombre.

Pour découvrir Snippy par vous-même: http://www.think-snippy.net.

Il s’agit en fait de fichiers « .replacelist » et « .insertlist » (respectivement, pour remplacer la liste, ou insérer une liste à l’emplacement courant de la lecture, selon le code source et mes tests).

Ainsi, si j’ai un tv.plb lié à un tv.pls, et que je veux insérer une liste de lecture à l’emplacement courant de la lecture, je vais créer ma liste sous le nom tv.insertlist.

Si je veux remplacer la liste de lecture avec une liste mise à jour, je vais créer ma nouvelle liste sous le nom tv.replacelist.

A la prochaine bascule de fichier, la playlist est chargée. Attention, le fichier « .replacelist » ou « .insertlist » est alors effacé.

I noticed that Darwin Streaming Server’s (dss) documentation about the playlist broadcast is not correct. Indeed, the playlist insertion/replacement module does not use « .updatelist » files.

Actually, it uses « .replacelist » and « .insertlist » files (resp., for playlist replacement or playlist insertion at current point, according to PlaylistBroadcaster.cpp and my tests)

So, if I have a tv.plb file bound to a tv.pls playlist and I want to insert a playlist just after the file currently playling, I copy my standard PlaylistBroadcaster list of to-be-inserted files as tv.insertlist.

And if I want to replace the playlist just after the current file has finished playing, I copy my new standard playlist file as tv.replacelist.

I hope this helps

J’ai pris le parti de développer mon mashup à l’aide de JavaScript, parce que les informations seront recueillies uniquement sur demande des utilisateurs de mon service.

L’idée est de proposer l’ensemble des résultats sur une phrase donnée pour les 3 moteurs cités ci-dessus, sous la forme d’onglets. Dans la mesure où l’on veut un site rapide et confortable d’utilisation, j’ai pris la décision de faire du tout-Ajax.

Problématique n°1: dans quel langue me parle-t-on ?

En effet, bien que les trois systèmes d’API externes proposent des résultats au format JSON (compris par pas mal de langages, PHP, C# et bien entendu JavaScript), le formatage des informations est complètement différent.

Yahoo! BOSS est laconique: tout est contenu dans un champ resultset_web (ou resultset_image, etc…) qui contient un tableau de champs result.
Microsoft Bing est très verbeux au contraire, et il faut parcourir trois ou quatre profondeurs dans l’objet JSON pour arriver enfin aux résultats
Google Ajax Search est le plus simple au niveau structure de renvoi mais sa limitation à 8 résultats par requête le rend fastidieux à utiliser, parfois. Mais bon, ça me fait jouer à l’algorithmique.

Les noms des champs, leur ordre et leur contenu varient évidemment selon le moteur que l’on interroge. Il s’agit donc, pour le salut de l’utilisabilité, de traduire cela dans un format universel (je vous laisse deviner le contenu, description, URL, …).

On écrit donc des algorithmes de traduction dans notre langage universel pour chaque résultat que l’on a récupéré en Ajax (une bonne utilisation des callbacks est requise pour ne pas se retrouver le bec dans l’eau).

A l’exécution, on va récupérer les résultats, traduire chacun de nos jeux de résultats dans le langage universel, et créer un objet d’agrégat (disons pour utiliser un terme branchouille un mashup) qu’on va pouvoir exploiter à l’affichage.

Problématique n° 2: la performance

Je suppose que vous vous rendez compte que dans le cadre de mon projet le volume de données à échanger avec des serveurs tiers est important. Afin d’optimiser l’expérience utilisateur, il peut être intéressant d’améliorer les performances de l’application.

La partie longue et ennuyeuse est la récupération des données et leur traduction en langage universel (l’affichage peut être fait assez simplement, avec un petit postback/callback vers PHP qui se chargera d’afficher les données à l’aide d’un moteur de template). Réduisons la donc à zéro pour les requêtes fréquentes (par exemple, « Jiwa », « Warez »,   »porn with horses and ponies », …) .

A la fin de la génération de l’objet JSON en langage universel, on le poste en Ajax vers un moteur de cache. Le fichier est alors mis en base de données, avec un timestamp en plus.

Au début de notre code de recherche, on ajoute une vérification: en Ajax, on interroge le moteur de cache pour savoir si les termes recherchés sont disponibles pour le type de recherche que l’on fait (web, images, news, …). « Disponible » signifie ici existant en base et récent (par exemple, moins de 8 heures). Si l’information est disponible en cache, alors au lieu de s’ennuyer à fabriquer notre objet universel à partir de requêtes toutes neuves, on se contente de donner à l’application le mashup déjà fabriqué.

Problématique n°3: Mais… <mon moteur de templates favori> n’est pas disponible pour JavaScript

C’est le problème épineux. En effet, faire du templating/formatage de HTML en JavaScript, ce n’est pas la joie, ni agréable, ni même esthétique. En plus, ça peut plantouiller. Heureusement, on fait du Web 2.0. Rappel de définition: on discute de manière asynchrone entre le client et différents serveurs. Good news, on va pouvoir se servir de cela pour faciliter notre affichage.

On a à disposition un mashup en JSON, que l’on souhaite afficher sous une forme agréable pour nos utilisateurs. Dans mon cas, par exemple, je souhaite me servir de contrôles Prado pour faciliter l’affichage. On va donc créer un service Ajax du côté serveur (en C#/ASP.Net, PHP, CFP ou ce que vous voulez) qui va manger le mashup que l’on va lui poster et ressortir du HTML. Une fois cela fait, il suffira de remplacer le .innerHTML de nos blocs de contenu.

C’est vraiment bien, le 2.0. C’est « The best of both worlds », côté client et côté serveur, servi dans un plat en argent, avec une grosse moto Yamaha en prime.

• Contenu stocké dans une base de données ou un fichier XML, bref, séparé du contenant.
• Menus stockés de même en statique.
• Une seule page et des anchors.
• Le contrôleur est une page php.  On teste l’User Agent.
  • S’il s’agit d’un crawler, alors on affiche une version HTML basique du contenu (pas de CSS, on simplifie au maximum, mais respect de la sémantique, titres, paragraphes, etc).
  • Sinon on affiche une version Flash avec l’affichage désiré.

Pour savoir quelle page afficher, on teste l’ancre (ce qui est après le # d’une page, qui permet de se rendre à un point précis de cette page), ancre qui contient par exemple un chemin XPath ou un identifiant de contenu. De cette façon toutes les pages sont différenciées au niveau de leur URL et le référencement peut se faire (on peut pointer vers un contenu précis depuis une page externe). On a ainsi un site mono-page mais avec des URLs distinctes pour chaque contenu.

Ce qui nous aide dans le cas présent, c’est que PHP comme Flash savent lire l’anchor d’une page (pourvu qu’elle soit directement dans la requête). Pour faire en sorte que dans les liens PHP les pages soient individuelles (que la page recharge  à chaque fois) on met une valeur ?uniqid=un_identifieur_unique  pour obliger à recharger. Ainsi on s’affranchit de JavaScript, qui n’est pas supporté par la plupart des crawlers. Il va de soi que ce paramètre est ignoré par le contrôleur: il sert juste à différencier les pages pour le crawler.

Juste quelques notes de travail, inspirez-vous en si ça vous chante

J’ai eu envie de le mettre à disposition ici, afin de recevoir des suggestions, et peut-être d’inspirer des auteurs.

J’ai pour ma part réalisé une implémentation légère et efficace, CodeGuardian que je propose à la vente et à l’intégration. Ce n’est pas sous licence libre pour le moment.

Voilà le papier : Protéger une application PHP