Yoan Blanc’s weblog

Another swiss guy lost in Paris

September 2007

Pass me the bottle

Yoan BlancSun 23 September 2007, , , ,

RDF Resource Description Framework Icon. Playing with the microformats for a while now and made some tests with eRDF or RDFa, all those solutions have pros and cons. But all of them are about putting metadata inside existing (X)HTML documents (RDFa accept only XHTML). Sometimes, you don’t want to alter all your website, or maybe you can’t.

GRDDL has the concept of extracting RDF from existing content without altering it with XSL Transformation. Basically, it’s very similar that how Technorati extracts Microformats with Brian Suda’s X2V but the purpose of them isn’t to produce RDF but iCalendar, vCard or Atom (which is similar to RSS). Microformats are very domain-specific, unlike eRDF or RDFa (but RDF is far for straightforward).

GRDDL is a transformation stylesheet your link from your page, that will made this page readable by a computer. I havn’t found that much documentation, so what follows may be wrong, feel free to correct me.

Because Microformats doesn’t have anything for wine, and wine is a good subject to study ontologies, I managed to build a stylesheet that extracts RDF from Cork’d. Yes, Cork'd already provide a tool to export in XML but this one is reserved to people with an account and it offers to export your cellar only. The XML output format isn’t more verbose that the HTML already is.

This should able anyone to feed their triple database with more wine. I don’t know exactly the goal of this. Maybe if you are a content publisher and wanted to aggregate some content for third parties this could be a solution. I’m sure that 99% of the developers would build a regex-based engine. XSLT is cool because, you must give him valid XML (use Tidy), it deals pretty nicely with charsets. Reusability of pure-functionnal programming is often easier (from my point of view) than with declarative ones.

P.S.: I stopped drinking alcohol at the beginning of this year, so my cellar is empty on Cork’d (and I cannot delete my account). Sob.

Je joue avec les microformats depuis un moment déjà, ai testé pour le fun RRDFa et eRDF qui ont pour but de normaliser certains types de contenu dans une page internet. Le but est prémacher le travail des moteurs qui indexent les pages ou de permettre des outils comme Operator qui rendent (du moins devrait) notre vie de tous les jours plus agréable (encore). Hélas ces solutions impliquent d’enrichir la sémantique des pages existantes ce qui n’est pas toujours simple ou faisable.

Et là, le W3C nous propose GRDDL qui a comme concept d’attacher aux pages une feuille de transformation XSL allant permettre la génération de RDF comme on peut l’aimer. Le principe est assez similaire au X2V de Brian Suda qu’utilise Technorati. Les microformats sont spécifiques à certains domaines, eRDF, RDFa ou GRDDL s’appliquent à tout ce qui ne facilite pas les choses. Pour la belle loi de Pareto, 80% si ce n’est pas 90% des besoins sont couverts par les microformats, pour le reste il faut mettre les mains de le cambouis.

J’ai écrit une petite feuille de style XSL permettant d’exporter une description oenologique depuis Cork’d en RDF selon l’ontologie Wine (qui n’est pas une mince affaire).

Le résultat n’est pas forcément ok, n’étant pas expert en la matière (merci de me faire vos commentaires). Sinon Cork’d offre la possibilité d’exporter en XML, mais cette fonctionnalité ne s’applique qu’à son cellier et le format n’offre rien de plus que l’HTML déjà présent.

Passer par GRDDL pour extraire du contenu de pages est intéressant du point de vue d’un outil voulant aggréger du contenu de partenaires tiers (avec ou sans leur accord). Si 99% des développeurs vont opter pour une solution à base d’expression régulière, l’approche XSL est plus qu’intéressante car la réutilisabilité de ce qui est fait me semble plus grande, et les outils gèrent très bien les différents codages de charactère (ce qui n’est pas le cas de tous les langages).

P.S.: ne vous étonnez pas de trouver mon cellier vide sur Cork’d je ne bois plus.

(pseudo-)yield in JavaScript: “be responsive”

Yoan BlancSun 09 September 2007, ,

I watched recently the nice video on YUI Theater about high performance in JS. And one thing I learnt, apart the fact that being lazy programmer isn’t a bug, but a feature, is that you can do a (pseudo-)yield in JavaScript (like in Python for example).

def countdown(max):
 for i in range(max, 0,  -1):
  yield i

Yes, it’s a little trivial… Don’t worry, the JS one is more interesting. The goal of yield is the let the browser refresh the display before continuing our task. A typical use of yield in wxPython is a progression bar. In JS, this is done with the well known timeout method: setTimeout.

function countdown(id, max) {
 var elem = document.getElementById(id);
 function show() {
  elem.innerHTML = max;
  max -= 1;
  if(max > 0) {
   setTimeout(show, 0);
  }
 }
 show();
}

I’ve made a page of examples (please visit the one from Joseph Smarr too). You can tweak how many times the show method will be called before letting the browser refresh. A refresh costs time too. Depending of the task, it’s good to say refresh every 10 operations or more. The goal is to have a responsive user interface that give the user a good impression, speed and reactivity.

My point of view is that this trick has to be applied if your ear some complains about the reaspeed of your web application, speed is different from reactivity, but as … said, your client cannot do the difference. Give the visitor as soon as possible something to see and try to truncate big operations with appropriate yields.

One side effect of that, is that you may have to deal with the timeout functions you calls. I don’t do it in my examples, but it should be good to be sure you don’t have any running yielding operations before running a new one. Double-click on a JSON button to see the glitch. Letting the browser display something, means letting the user interact with it. In case, you really want doing naughty thing this that, this could be useful: “Continuation-Passing Style”.

To avoid any confusion, I’m talking about pseudo-yield because yield exists in JavaScript 1.7 already.

J’ai récemment regardé la vidéo sur YUI Theater parlant de hautes performances en JavaScript, et y ai appris un point intéressant: l’usage du yield (un semblant de yield). Je le connaissais dans le langage Python pour fabriquer un générateur (très utile dans wxPython lors de la confection de barre de chargement) mais pas dans JavaScript (même s’il existe dans version 1.7 du langage).

Le but de yield est de rendre la main au navigateur au milieu d’une opération longue et douleureuse, pour qu’il souffle un peu et permettre à l’affichage de se mettre à jour. Voir l’exemple de Joseph Smarr sur la question. On peut imaginer, le remplissage d’une table avec beaucoup de valeurs par exemple. On obtient du navigateur qu’il rafraîchisse son état avec la méthode setTimeout à 0 qui va continuer l’opération en cours après avoir rendu la main. Ca donne un effet d’animation le plus souvent, qui n’est pas inintéressant.

J’ai fait plusieurs exemples, tous créant des nœuds DOM et les ajoutant à la page que je vous invite à essayer. Le premier va créer des étoiles par une méthode simple ou en se servant du yield tel qu’on l’a vu et le second va afficher un contenu JSON. Au lieu de tout créer d’un coup, on va en créer un certain nombre, les afficher puis continuer, ce qui se passe pour les étoiles, ça va accélerer l’animation.

Redonner la main au navigateur, implique que des actions peuvent être opérées également, il faut donc être prudent avec son usage. Ne pas relancer une opération, si une autre est en court. Chose que je n’ai pas faite dans mes exemples.

Pour répéter ce qu’on trouve dans la vidéo, la vitesse est souvent une impression de vitesse et donner au plus vite un retour visuel de l’opération en cours est le meilleur moyen de maintenir le visiteur attentif et ne pas lui faire perdre patience. Ce que tous les sites en Flash font depuis leur naissance. D’abord informer qu’une opération est en court, puis afficher dès que possible du contenu.

Yet a more secure MP3 player and server

Yoan BlancMon 03 September 2007, , , , , ,

I finally managed to build a secure, I mean a thing that I cannot break, Flash based MP3 player. Someone else will break it, please do!

It takes its inspiration into the (old) Atom API documentation, but due to the limitations of the embedded Flash player itself, I adapted it. So less HTTP headers and more GET or XML datas. What is important is that every call to a file is unique and you can’t fake it.

Let’s dive. I created a very basic song player with the free (as in beer) Flex SDK. As I’m using GNU/Linux by night I don’t have the choice if I want to produce a SWF.


one list, 4 buttons, it’s already too much.

This player browse a RSS feed, the same that the one you use for a podcast and loads the songs.

The Atom API protocol, works with one shared secret, the user password and one counter that works like a ticket.

  1. Client: Gimme the song “a.mp3”
  2. Server: No way man, please identify your self!
  3. Client: I’m “Yoan”, with ticket 1, gimme the song “a.mp3”, please.
  4. Server: Okay, there it is.
  5. Client: I’m “Yoan”, with ticket 2, gimme the song “b.mp3”, please.
  6. Server: Okay, there it is.

You cannot cheat the ticket counter and whole informations are encrypted to build a unique string that the server can rebuild on it’s side to verify.

Last but not least, disable the cache with the appropriates HTTP headers. I won’t explain you in details how it works, just grab the files bellow (at your own risks), fill the RSS feed with your songs (that must be in the same directory) and test by running twistd -ny mp3.py and visiting: http://localhost:8080/ (it’s your own box).

I would be really happy to see this solution used somewhere, there is lots of work to do. But the concept it here. Feel free to ask me. It was my first tries with Flex and Twisted.web2 by the way. As far as I know, you cannot decompile a SWF generated by the Flex compiler but I would advise you to crypt it anyway.

Et voilà, j’ai fait chauffer mes méninges pour mettre sur pied un système client/serveur permettant de diffuser des mp3 à la demande où on ne peut pas récupérer les dits MP3 simplement. Parti de la constation que trop peu de services font attention à ce détail là: MySpace et Mx3 sont ceux qui, à ma connaissance, offrent une protection sérieuse.

Le but du jeu est d’avoir une URL unique par fichier demandé, non réutilisable et authentifiée. Ne voulant réinventer la roue, mon choix s’est porté sur l’Atom API qui date peut-être un peu. Et à cause des limitations pour des raisons de sécurité du lecteur Flash des navigateurs la pluspart des informations transittant via entêtes HTTP passent ici en GET ou dans le corps du message (dans un format XML).

Le fonctionnement est assez simple et repose sur un secret partagé (un mot de passe) et un compteur qui permet d’éviter la rejouabilité d’une requête. Les deux parties possèdent ces informations, mais le mot de passe ne transite jamais entre les deux ce qui devrait garantir une protection suffisante. La seule faille étant d’obtenir le mot de passe en décompilant le fichier SWF ou en ayant accès au serveur.

N’ayant pas envie de détailler tout, ce qui me prendrait quelques heures et est digne d’un rapport scolaire (non merci), je vais vous laisser jouer avec les fichiers ci-dessous, qu’il faut compléter par les fichiers audios de Backini (ou les vôtres en adaptant le flux RSS). Une fois le serveur lancé twistd -ny mp3.py vous avez accès au lecteur via l’adresse suivante: http://localhost:8080/. C’est un simple serveur local sur votre machine.

Bien sûr, utilisez-ceci à vos risques et périls, un ennui est si vite arrivé. N’hésitez pas à essayer de casser ce système, même s’il y en a de bien plus facile parmi les sites publics. C’est mon premier essai avec Flex et Twisted.web2 donc, il y a certainement moyen de faire bien mieux. Sinon, à votre disposition pour d’éventuelles question.

About

meYoan Blanc is a web developer that lives in Paris (19, rue Bichat75010France) works for Yahoo! and comes from Switzerland ( La Chaux-de-Fonds). This web site is for this weblog, a playground for random stuffs and can help keepingconnected with some friends out there.

Get my vCard or contact me by phone (+33 1 74 30 12 92) or email ().

Misc

RSS, list.blogug.ch

This site reflects only my opinion and is not affiliated with my employer.

copyright 2006-2007 — doSimple.ch