Matronix.fr Le blog d'un prof de primaire
Je ne vais pas troller, car je sais à quel point c’est douloureux de perdre ses données. Mais une petite piqure de rappel s’impose. Dans le monde de la presse, il existe une société nommée GLI qui s’occupe de la gestion des abonnements en tant que prestataire pour de nombreux groupes de presse français. Les Echos, le Figaro, > Lire la suite
Source : La moitié des groupes de presse français viendrait de perdre toute trace de leurs abonnés – Korben
C’est pour ça que récemment je suis passé de o2switch qui ne propose à peu de choses près pas de sauvegardes, à Web4All (même prix sans l’illimité) qui propose des sauvegardes de tout et de manière très complète.
J’ai d’ailleurs résilié mon abonnement Google Apps for Work et j’utilise la solution Zimbra de Web4All qui marche très très bien maintenant (en particulier leur antispam). Couplé avec un bon client mail (Airmail 3 sous Mac et iOS).
Le seul défaut de Web4All c’est de ne pas proposer encore de tâches cron. Mais en fait je n’utilise plus depuis un moment de lecteur RSS auto-hébergé. En cause la lenteur de la base de données (j’ai pour habitude de bourriner un peu la touche N pour passer à l’article suivant, et attendre environ 1 à 2 secondes que la base de données se synchronise me gonfle). J’utilisais Feedly, mais il ne garde que le dernier mois des flux. Maintenant j’utilise The Old Reader en version payante ($3/mois), et conserve 1000 articles par flux pour un maximum de 500 flux. Je suis tranquille et plus stressé par la lecture de mes flux du coup. J’ai couplé le service avec Reeder sur Mac et iOS, c’est top.
Nous avons le même combo : Web4all + Zimbra + The Old Reader
J’apprécie le fait que Web4all soit une association loi 1901.
Pour le lecteur RSS, vu que j’en développe un aussi, je me suis également heurté à ces problèmes de lenteur et de connexions navigateur/serveur incessants.
J’ai résolu le problème avec deux astuces :
– le tri, l’ouverture, la lecture est faite dans le navigateur (en JS) : toutes les données sont transmises une seule fois au navigateur. Ça fait un peu de données (500 flux non-lu prennent 2,2 Mo dans la page — ce qui reste toujours moins qu’une page pleine de pub et de scripts), mais après c’est très fluide.
– je ne mets pas à jour à chaque ouverture de flux. Je fais un cache en JS. Chaque fois que 10 articles sont lus, hop, je fais une connexion au serveur pour lui dire de les marquer comme lus.
Si on ne lis que 7 articles et qu’on ferme l’onglet il reste 7 articles lus qui ne sont pas encore marqués comme tel. JS connecte le serveur juste avant de fermer l’onglet pour mettre à jour le serveur. Comme ça je n’ai aucun problème de synchronisation, même si c’est fait de façon asynchrone. Le seul problème c’est si le navigateur plante, mais ça, ce n’est pas de mon ressort :p.
Et avec quelques astuces JS et de l’optimisation, c’est suffisamment fluide pour fonctionner sur un smartphone pas trop puissant.
C’est bien que tu prennes en charge ces problèmatiques. De tous les lecteurs RSS que j’ai testés (j’ai plus les noms en tête mais les plus connus, type Fresh…) ils ne prennaient pas en compte ce problème.
Les grands services type Feedbin, Feeder, The Old Reader etc ont tous une compatibilité avec de grandes applis comme Reader. Ce sont les applis qui se démerdent ou elles utilisent des API fournies ? Ton service ne peut pas devenir compatible avec les applications de RSS ?
Mon outil n’est pas un service et pas d’API. C’est lui l’application RSS.
Enfin, si les grands services sont rapides, c’est à grand coup de CDN et de serveurs super-rapides. Ça aide aussi. Dans tous les cas, il me semble suicidaire (pour le serveur) de faire tourner un programme qui fait une requête à chaque clic : tu imagines le nombre de requêtes que ça fait chaque jour pour quelqu’un fait sa veille de cette façon ?
Ils ont aussi des connexions persistantes, je présume, qui permettent de faire des requêtes plus rapides. Les réseaux sociaux arrivent ainsi à être rapides et à mettre à jour les données en temps réel (nombre de like, etc.).