Bonjour mes amis,

Étant relativement jeune, je ne découvre qu'aujourd'hui ce chef d'½uvre : j'ai bien cru que ça venait de sortir, mais non, ça date de 1981 (voyez la ressemblance avec les génériques des animés Dorothé de l'époque).

Sechez vos larmes, la campagne de 2007 n'est pas encore vraiment lancée et vu comme Sakozy fonce sur tous les médias...

La fameuse : http://graou.org/found/chirac/ (je n'ai mis qu'une minute pour des raisons de droits toussa, mais c'est excellent sur toute la durée)

> Lire le journal (2 commentaires, moyenne: 0,5).

Rapide, sobre, multi plateformes : GBrowser, le navigateur de Google existe !
Une version d'essai est disponible ici : http://evain.net/gbrowser/(...) :)

> Lire le journal (12 commentaires, moyenne: 5,3).

Je profite de mon "pouvoir" temporaire, qui est celui de pouvoir poster un journal public pour donner un peu plus de visibilité au journal "Qui sommes-nous? Sociologie du "monde libre"" : http://linuxfr.org/~Clemsoun/16774.html(...)

Je trouve sa démarche intéressante, même si je pense que l'enquête en elle-même est incomplète. Je pense qu'un 'ouvrage' qui traite du monde libre, quel qu'il soit ne peut être que positif, donc je vous encourage à participer, et à commenter son travail : apparemment, il n'en est qu'au début de son travail, donc encore influençable :)

> Lire le journal (2 commentaires, moyenne: 1,5).

Mono avance tous les jours, mais aujourd'hui en particulier, puisque Cecil vient d'y être ajouté. Cecil est un module de Reflection écrit par Jb Evain. Allez donc voir les sources, c'est de toute beauté !

Plutôt que de répéter, je vous envoie vers son post : http://blogs.dotnetguru.org/jbevain/index.php?title=cecil_feed(...)

> Lire le journal (21 commentaires, moyenne: 4,1).

Une chose que je constate depuis fort longtemps, et qui m'interpelle est la mauvaise utilisation des protocoles et standards/formats qui, malheureusement, deviennent souvent des habitudes, puis des 'comportements par défaut'. À qui la faute ? Aux développeurs je pense, qui, sous prétexte de simplicité contournent les protocoles, pour souvent un fort gaspillage en ressources : CPU et/ou BP. M'est avis que les avantages obtenus en procédant de cette façon sont récupérables en travaillant plus sur les logiciels d'interfaces...

Voilà donc le premier d'une courte série de journaux sur des 'détournements' de protocoles/formats.

La syndication de contenu est, à mon sens, la "technologie" phare de l'année 2004. La révolution des weblog l'a fait devenir de plus en plus populaire et elle a été adoptée par tous les acteurs ayant une utilité dans la syndication : bref, c'est un carton !

La syndication désigne le fait de réutiliser une source d'information afin de partager du contenu. Les objectifs initiaux de Netscape étaient clairs et simples : permettre à leurs partenaires d'apporter eux-même du contenu sur le portail Netscape. C'est à dire du server to server. Ensuite, UserLand est reparti des travaux de Netscape pour ses outils de weblog.

Le problème, je pense, est apparu avec l'arrivé des aggrégateurs ou newsreaders. Même si RSS s'est sensiblement amélioré depuis, et que Atom a intégré ces améliorations : gestion des dates, etc, je pense qu'il n'est toujours pas adapté aux utilisateurs.
En effet, on a actuellement sur les flux des milliers de clients qui téléchargent le flux des dizaines de fois par jours : le comportement par défaut de mon lecteur est réglé sur un rafraîchissement toutes les 5 minutes, soit 120 requêtes pour 10h d'activité et par flux !

Vous imaginez sans doute le gâchis. Sur la cinquantaine (je ne suis pas un addict, loin de là) de flux auxquels je suis inscrits, 90% ne sont même pas mis à jour quotidiennement. Je pourrais alors simplement configurer ces flux pour qu'ils soient individuellement rafraîchit moins souvent, mais j'aime être au courant __tout de suite__ des mises à jours : c'est normal, je suis un utilisateur lambda.
À cela, on peut aussi ajouter le fait qu'aujourd'hui la plupart des outils de weblog publient du RDF encapsulant de l'HTML pour le contenu, ce qui, si c'est très pratique et très agréable à lire, rend le fichier un peu plus lourd. De plus, RSS ayant aboli la limite des 15 items par flux, et Atom aussi...

Le problème est donc clairement un gaspillage incroyable de ressources, essentiellement réseau.

En terme de solutions, la plus évidente me semble être de séparer le champ de dernière modification du reste. Pour ce faire, on peut imaginer facilement un système de SOA, comme pour le DNS ; par exemple, avec un format XML simple décrivant l'adresse de la ressource de contenu à la manière de la balise LINK d'HTML. Cette solution conserve la simplicité technique d'RDF et la possibilité de tout gérer sans middleware.
On peut aussi imaginer une technique plus souple en terme de communication, mais plus lourde coté serveur avec un vrai service web et WDDX.

D'un point de vue plus théorique, et pour plus d'efficacité, on pourrait imaginer un système qui renverserai le problème. En effet, on est ici dans un cadre 1 to any où un contenu périodique s'adresse à beaucoup de monde. Dans le genre, il existe déjà les mailing-list, et c'est peut-être par là qu'il faille chercher la solution.
Imaginons un futur en IPv6, un utilisateur pourrait signaler au serveur qu'il est disponible, enregistrer son site dans un groupe et tout simplement attendre que le serveur envoie un multicast (UDP ?) pour signaler une mise à jour à chaque nouveau contenu. Je ne sais pas vraiment si c'est possible, je ne suis pas du tout au fait d'IPv6, mais s'il est en plus possible de récupérer au niveau logiciel les informations sur la durée de vie de l'adresse, on peut croiser cette information avec le reste pour minimiser les transferts inutiles.

Bref, tout ça me semble fortement perfectible. Avez vous des idées de solutions ? Voyez vous d'autres problèmes dans les versions actuelles ? Ai-je présenté des erreurs ?

> Lire le journal (14 commentaires, moyenne: 3,3).

Afin de finir cette année 2004 en beauté, je vous livre ma dernière idée "cabinets".

À l'heure actuelle, pour effectuer une traduction, qu'est ce qui est disponible gratuitement et facile d'accès ? Google Translate et les dérivés de SYSTRAN :BabelFish et cie.

Le problème de ces systèmes ? Ils font du mot à mot ou presque. En prenant le problème à l'envers, on s'aperçoit vite que pour avoir une traduction correcte, l'intervention humaine est nécessaire. Bien sur, pour un outil de type GT (Google Translate), c'est impossible me direz vous, et bien non, je ne pense pas. Si l'on réfléchit à Wikipédia, le problème est proche et résolu !

Mon idée est donc de créer un GT collaboratif.

Comment ça marche(rait) ?
D'un point de vue utilisation, ce serait sensiblement comme les solutions actuelles. Là ou ça change, c'est que l'on n'utiliserai pas un dictionnaire "fixe" de mots à remplacer, mais une "base de connaissances".
Par exemple, je veux savoir comment traduire "À qui la faute ?" en anglais. GT me donne "With which it fault?".
Là, le système me proposerait (ou pas) tous les groupes de mots présent dans la base de connaissances.

Le principe est donc que chaque expression (au sens lyrique et syntaxique) soit ajoutée au fur et à mesure dans la base pour tendre vers une exhaustivité (impossible) de tous les groupes de mots.

En pratique, pour le 'remplissage', j'imagine ça sur croisement entre le fonctionnement de bugzilla et le système de score de linuxfr.

Techniquement, il y a de petits challenge notamment au niveau de l'ergonomie, mais rien d'impossible. Le problème, à mon avis, serait de le populariser.

Je n'ai réfléchi que sur une base français/anglais pour le moment (donc latin), mais ça doit pouvoir fonctionner pour tout, et ça permettrai sans doute d'avoir accès à des langues 'peu rentables' et donc actuellement indisponibles.

Bref, comme c'est une idée eu aux toilettes, je l'ai pas énormément poussée, mais je trouve ça intéressant : qu'en pensez vous ? Est-ce que ça existe déjà ? Voyez vous des limitations ?

> Lire le journal (10 commentaires, moyenne: 2,4).

Je viens de me rendre compte en recevant un mail via Gmail (merci Jb !) que pour décrire minuit et 25 minutes, l'affichage 12 heures (anglo-saxon) est "12:25am".
Je trouve ça vraiment à chier. En effet, l'affichage 12h est censé représenter deux cycles de douze heures chacun. Si les deux cycles doivent être de douze heures pourquoi ne pas les faire aller de 00:00 à 11:59 ? C'est insensé ; ça signifie que lorsque nous avons 00:25 en 24h, aujourd'hui par exemple, le lundi, on est encore (en 12h) dans le deuxième cycle du dimanche après midi.

> Lire le journal (25 commentaires, moyenne: 2,8).