Je ne dis pas qu’il faut le faire en bit à bit avec le header déjà standard. Je dis juste qu’il y a moyen d’appliquer soi-même le draft-ietf-httpbis-p5-range-latest (par exemple en préfixant les headers avec x- pour rester sur du fait maison le temps que le standard soit poussé).
Ou alors tu peux inventer ton propre protocole maison avec un ou deux headers du type x-from x-to que tu fais interpréter par ton serveur.
Count me in, quelques pistes :
Sinon je me penche dessus plus serieusement ce soir, tu comptes faire un github et quel tehcno ?
(j’ai juste lu en diagonale le thread).
En fait je me posais juste la question, comment on ferait avec les moyens qu’on a aujourd’hui, pour faire ce lecteur de flux rss sans avoir besoin d’une usine côté serveur.
J’ai fait quelques tests avec un proxy en nodejs, c’est super rapide et ça bouffe rien, à part la bande passante bien sûr.
Si on n’autorise que les fichiers avec un type mime xml, en gzipé ça pèse pas bien lourd. Avec un petit script exécuté par une dizaine de clients ça devrait être assez simple à benchmarker, et comparer ce que consomme le même petit proxy en nodejs, en go ou whatever.
Si tu veux de la synchro avec une application 100% client, 0% serveur, c’est du côté des protocoles P2P qu’il faut regarder. Mais à mon avis sur mobile tu vas vite te heurter aux problèmes suivants :
1/ Le plus gros ça va être la sécurité
Comment s’assurer que quelqu’un ne va pas pouvoir attaquer ton appareil en se faisant passer pour un autre appareil que tu possèdes ? Il va falloir une clé privée par appareil, et N clés publiques (pour les autres appareils abonnés). C’est compliqué à mettre en oeuvre (renouvellement des clés…). Alors qu’en centralisé tu as un seul certificat.
2/ Assez génant aussi, le coût en batterie et data
Décentraliser la donnée, ça veut dire augmenter le nombre d’échanges (1 vers N = N échanges en centralisé ; N vers N = N(N-1)/2 échanges en décentralisé). Ou alors il faut utiliser un graphe incomplet pour diminuer ce nombre, mais ça augmente la probabilité de bloquer plusieurs noeuds du graphe par l’indisponibilité d’un seul des noeuds (pire cas : le graphe en anneau).
3/ La mise à niveau de l’appli
C’est compliqué de gérer la rétrocompatibilité de N clients pas tous à la même version avec un serveur, alors en décentralisé c’est encore pire.
4/ L’ergonomie
Indiquer quel appareil est synchrone par rapport à quel autre, c’est juste une horreur à gérer.
En bref, tout ce qui fait que le décentralisé est génial, je ne dis pas que ça n’existe pas. Mais ce n’est pas pour rien que ça n’est pas le mode utilisé de base. Quand tu regardes des outils décentralisés comme Git, la complexité qui est derrière est bien supérieure à celle du même outil centralisé, et l’ergonomie est très dégradée par certains côtés (l’utilisateur doit être un expert).
[quote=“Histrion, post:24, topic: 55185”][/quote]
Apres tu as des bases de données en distribués qui font le boulot hein …
(surtout le nosql).
MongoDb, Couchdb et j’en oublie surement.
Et rien n’empeche un truc batard.
(Les gros pcs font serveurs ou gere les conflits and co et les mobiles sont clients legers).
Apres tu as aussi des gestionnaires de queus a la celery ou rabbitmq qui peuvent justement gerer une file d’attente de notification, pour la synchro.
Sinon dans les idées folles que j’avais eu, c’etait de faire de la synchro et du P2P par email.
Je m’explique :
Chaque appareil a un compte email quelquepart.
Quand le mobile X lit un flux il envois un email aux machine Y (y@toto.com), Z avec le flux lus en entier et la date a laquelle il l’a lu.
Quand Y se connecte ou lance l’appli il recupere les emails de y@toto.com et s’en sert pour faire sa synchro car il a :
Quel appareil a consulté quoi par email , la date d’envois et la date de reception.
Et si tu veux te la jouer parano tu fais un systeme de clef privé / public ou chaque appareil a, les clefs publiques des autres pour verifier la provenance de l’email.
Et en plus l’email est totalement decentralisé.
Finalement, le truc du serveur mail de Bussiere me fait penser que le seul moyen de faire une appli “décentralisée” est de masquer l’aspect centralisé, après tout le serveur mail est un moyen de centraliser les informations tout aussi bien que Google sync par exemple.
Et c’est tout à fait normal car il faut bien une source centrale à laquelle se fier quand la synchronisation demande de faire un merge de flux contradictoires provenant de plusieurs sources.
De plus un serveur sur lequel on peut se connecter 100% du temps est forcément plus fiable que des sources clientes qui peuvent se déconnecter voire être éteintes.
Finalement quitte à être indépendant, peut être faut-t-il monter son serveur chez soi pour gérer ses flux RSS, je crois que cette solution existe déjà d’ailleurs.
[quote=“Mimick, post:26, topic: 55185”][/quote]
Apres, tu peux multiplier les serveurs emails aussi hein, chaque client peut avoir son serveur email.
Juste que la j’ai en tete un reseau social qui serait un site web construit a partir d’une grosse mailing liste et de mails.
Chaque user construit un site web a partir des emails recus par ses contacts.
Bref pour m’etre un peu penché dessus l’email peut etre asez sympas comme enveloppe pour des données :
Quelle que soit la solution technique, s’il s’agit de faire tourner N fois l’application (une fois par appareil), plutôt qu’une fois de manière centralisée, ça aussi ça a un coût. Et faire tourner un serveur NoSQL c’est pas gratuit à la fois en proc, mais aussi en RAM (denrée un peu rare sur les mobiles), et donc en batterie (encore plus rare)…
Quant au serveur email déporté sur les clients, à mon avis vous êtes dans l’overkill. Vous voulez juste un mécanisme de push ou de pull. Le faire via SMTP au lieu de HTTP, je ne vois pas le gain. Le mail c’est compliqué, selon les opérateurs mobiles il y a plus ou moins de tolérance pour le laisser passer à forte volumétrie, et selon les OS ça va peut-être passer par des API qui vont forcer à implémenter les choses dix fois.
De manière générale, si c’est pour du mobile, pour au moins encore cinq ans vous pouvez oublier le décentralisé, sauf à faire quelque chose de très léger. Et encore le sens du Web actuellement c’est de centraliser de plus en plus (Cloud).
Et faire autre chose que du HTTP sur le Web, c’est vouloir des problèmes.
[quote=« Histrion, post:28, topic: 55185 »][/quote]
Pas faux, mais pour les emails je ne pensais pas forcement a mettre le serveur sur le telephone.
Il y a un serveur sur le net par telephone en email X est chez hotmail, Y chez gmail , Z chez yahoo par exemple.
Chacun recupere ses emails, avec les infos de synchros, et quand X regarde un flux il email tout le monde pour dire qu’il a regarde tel flux, ou il email juste un central (Mailing liste qui email les autres).
Tu peux faire plusieurs maillage.
L’avantage c’est que qeulquesoit ta becane (tel ou pc) envoyer un email en prog ou le recuperer est facile.
Surtout que dans mes souvenirs tu peux , juste regarder l’intitulé d’un email avant de le dl en entier donc si tu fais bien ton subject tu peux choisir quels emails dl.
Et ca se decentralise facilement.
Apres c’est juste une idée et mon point de vue 
Dans ce cas tu as même plus simple : le SMS 
[quote=« Histrion, post:30, topic: 55185 »][/quote]
Je ne sais pas si on peut consulter l’intitulé d’un sms avant de le dl ni mettre une piece jointe avec.
Sans compter que tu peux avoir data illimité* mais pas sms illimité 
Sans compter wifi a l’etranger mais roaming en sms …
Mais oui a creuser.
Exact. Encore une fois, HTTP !
Si j’ai bien compris l’exposé on a fait un truc un peu rigolo au boulot pour gérer ces queues à la place du HTTP ou du SMTP:
on a mis un serveur IRC privé avec chaque crawler qui poste ce qu’il fait. On peut même leur donner des ordres ainsi
Original. Ca me rappelle les bot’ IRC à l’école. Bon quitte à donner dans les protocoles à la c… ça me rappelle cette planche
http://www.nojhan.net/geekscottes/index.php?id=118
(merci pour le strip, c’est bookmarké :D)
Sur les 15 premiers comics, y a 30% de trolls sur Windows. Comme c’est étonnant…
[quote=“Lupuss, post:36, topic: 55185”][/quote]
Heu… Avec des gnous et des pingouins partout dès le premier… What did you expect?