parler de patrimoine, c'est considérer chaque génération comme l'usufruitière d'un bien dont ell a hérité, avec obligation de transmettre quelque chose d'équivalent afin de garantir les conditions de vie de ses successeurs.
— Penser et agir avec la nature - Catherine Larrère, Raphaël Larrère, urn:isbn:978-2-3480-3627-9
Robin Rendle a écrit un essai à propos des newsletters. Depuis quelques temps, de plus en plus d'auteurs se tournent vers la newsletter pour communiquer avec une communauté. Je ne suis abonné qu'à une seule newsletter : Roden de Craig Mod.
Robin explique que l'attraction pour les newsletters tient à trois paramètres :
Alors pourquoi cela fonctionne par mail et cela ne fonctionne pas sur le Web. Robin pense que la technologie est là mais n'est pas déployée : flux RSS ou Atom dans le navigateur (Firefox a récemment enlevé le détecteur RSS plutôt que de l'améliorer, malheureusement) et W3C Payment Request API. Certes cela peut aider. J'utilise NetNewsWire pour mon lecteur de flux et ne pas avoir à visiter les sites. C'est un système de pull.
L'email est un système de push et cela change beaucoup de choses. Il y a une notion d'intimité qui est importante et qui définit un plus grand contrôle. La newsletter n'atteint pas potentiellement tout le monde, uniquement ceux qui ont voulu s'inscrire (et potentiellement payer). Créer un site Web intime, c'est à dire gérer le contrôle d'accès est plus difficile.
| Type | Auteur | Vers | Lecteurs |
|---|---|---|---|
| Web | One | ⬅︎ | Tout le monde |
| Newsletter | One | ⮕ | Quelques personnes |
Je pense que toutes les pièces sont là pour en effet permettre un système similaire aux newsletters d'exister mais en effet il faut que les navigateurs et les propositions de services est un scénario simple pour le micropaiement et le contrôle d'accès.
Peut-être un système mélangeant Payment Request API avec « Atom as notifications. » Mais les notifications ne gèrent pas l'archivage de celles-ci, ni le navigateur, on en revient à Browser Tabs Time Machine.
J'ai travaillé récemment sur ce bug (la PR avance bien) de la librairie HTMLParser.
data:text/html,<!doctype html><div class=bar ,baz=asd>text</div>
était sérializé par les navigateurs en
<div class="bar" ,baz="asd">text</div>
alors que HTMLParser allait en erreur. Mais j'ai trouvé un autre bug pendant la discussion.
data:text/html,<!doctype html><div class="bar" class="foo">text</div>
est sérializé par les navigateurs en
<div class="bar">text</div>
mais HTMLParser donne:
<div class="bar" class="foo">text</div>
J'ai ouvert un nouveau bug sur le projet. Il y a d'autres bugs intéressants pour HTMLParser. Probablement aussi, le HTMLParser est plus un tokenizer qu'un parser html.