31 réponses à ce sujet

[Stark]

Ouep. J'ai mis une période assez arbitraire en fait ^^
Pour les extensions, oui, j'pense qu'il faudrait en fait définir à chaque installation un random, ou se baser sur l'heure d'installation pour déclencher les mises à jour de la BDD.
Histoire que tout le monde ne se mette pas à jour à 0h00 pile.

Et si la charge est trop importante, je mettrais NginX en frontal pour alléger la charge du serveur sur les fichiers de BDD. Il s'en sortira largement mieux qu'Apache.

Mais en "harmonisant" bien la charge, ça devrait très bien se passer. Comme dit, je doute que la BDD va peser plusieurs Go. Déjà si elle atteint le Mo ça sera pas mal !

Je vais regarder s'il existe pas des librairies JS pour dézipper un fichier. Parce que si y'a ça, on pourra même se payer le luxe de transmettre des fichiers compressés (et diminuer la charge encore plus).

[Stark]

Il existe JSZip pour JavaScript qui fait ça. Pour PHP, y'a l'extention ZIP mais elle n'est pas activée par défaut (donc ça pose un problème). Cependant, en général quand t'a un wordpress ou un CMS quelconque d'installé, cette extension est active ...
Remarque : il n'est pas forcément nécessaire pour une extension de CMS de télécharger le fichier en ZIP (parce qu'ils ont bien souvent une connexion en 100Mbps et qu'ils verront pas la différence). C'est je pense surtout intéressant pour les plugins de navigateurs, enfin, dès que l'internaute télécharge la bdd (c'est plus sympa de télécharger quelques Ko que quelques Mo). Et c'est surtout les connexions à "bas débit" qui font mal au serveur (puisqu'elles durent plus longtemps que les autres).
Si vous pensez qu'on peut utiliser JSZip, ben c'est cool. Sinon ça passe à la trappe ! (j'ai pas regardé ce que ça donne, aucune idée de si c'est une usine à gaz ou pas)


Edit [16h47] :
Je viens d'avoir une idée pour l'infobulle. En plus de l'afficher au survol de la souris (événement Hover), je propose qu'on "intercepte" le clic sur le lien menant vers le site liberticide, et qu'on affiche alors l'infobulle. ça permettrait alors d'être sûrs que le message est vu par l'internaute (car pas dit qu'il fasse attention au hover, et surtout, si c'est un utilisateur d'écran tactile il n'y a pas d'event Hover^^).
Dans l'infobulle, il faudra alors ajouter deux liens, du style : "Oui je veux aller sur ce site et participer à la mort du Net Libre" (xD) et "Non je veux rester ici".
Dès lors, et étant donné qu'on affiche des textes d'actions "sensibles" (si l'utilisateur ne comprend pas, il est bloqué quoi), il faudra gérer la localisation de ces messages. A partir de la langue du site ou bien à partir de celle de l'utilisateur. Je préconise celle de l'utilisateur ^^
étant donné que ces textes "ne sont pas bien compliqués", on peut à la limite utiliser un outil de traduction automatique pour faire ça (dans un premier temps).


Edit [17h23] :
Sinon, point important. On a tout ce qu'il faut pour développer le projet. Par contre il va nous manquer des gens pour remplir la base de données ...
Je propose déjà qu'on réfléchisse à ce qui devra apparaître dans cette base, et ce qui ne devra pas y être. Voici une liste non exhaustive de ce qu'il faudrait je penser recenser :

• Les sites des entités légales / gouvernementales / politiques / administratives ayant affiché leur soutient à des propositions de lois liberticides / ou des moyens de censure / ou des dispositifs d'attentes à la vie privée (on se limite à l'internet ? parle-t-on des histoires de lien fort avec la nouvelle CNI ? des SMS "furtifs" ?)
  
• Les sites des entités commerciales développement des moyens de censure / atteinte à la vie privée, ainsi que leurs clients, et leurs actionnaires.
  
• Les sites des entités commerciales ayant demandé des moyens de filtrage, de censure et d'atteinte aux vies privées, ainsi que leurs clients et actionnaires.
  
• Les sites des personnes (physiques ou morales) ayant affiché leur soutient à ces lois /moyens ...

Je ne sais pas s'il faut aller aussi loin. Juste à titre informatif, le fait de recenser également les actionnaires de Vivendi (maison-mère d'Universal), on ajouterait à notre liste les sites suivants : BNP Paribas, Crédit Agricole, Banque Populaire, ...
Ou alors, faut-il se limiter aux actionnaires "majoritaires" (ceux qui détiennent plus de 50% d'une société, plutôt rare dans le cas de Vivendi puisque le plus important (Crédit Agricole) n'a *que* 4%) ?

Bref, on a besoin de volontaires pour réfléchir à tout ça, et pour peupler la liste des sites recensés par le Projet !

[hugolegrand]

Petit poste plus technique

Voila comment j'ai pensé la bdd a emporté avec les extensions:


Domaines

En effet, j'ai séparé domaine et description, car je pense que plusieurs domaines (surtout pour plusieurs sous-domaine d'un domaine) peuvent se rattacher à une même description.
Je pense aussi que l'on ne peut considérer que les domaines. En effet, les plateformes telles wordpress.com héberge de nombreux sites sous différent sous domaine, ces sites pouvant tout aussi bien être pro que anti SOPA.
Enfin, je pense que les noms de domaines (ou sous domaine) doivent concerner à la fois le www.xyz.com que le xyz.com, respectivement le www.blog.xyz.fr que le blog.xyz.fr.
En ce qui concerne "domain", cela contiendra le nom de domaine ou de sous-domaine concerné. "allsub" signifie que tous les sous-domaine de ce domaine (ou tout les sous-sous-domaine de ce sous domaine ^^) sont concernés par cette description. Je pense que nous nous limiterons au sous-domaine et que l'on laissera les sous-sous domaine, c'est rare.
Donc pour résumer

• domain => xyz.com , allsub=> 1, concerne *.xyz.com et www.*.xyz.com
  
• domain => blog.xyz.com, allsub => 0, concerne blog.xyz.com et www.blog.xyz.com
  
• domain => xyz.com, allsub => 0, concerne xyz.com et www.xyz.com

Et voici un petit schéma pour le traitement des url:

[The Datawolf]

Alain Ternaute, le 26 janvier 2012 - 12:51, dit :

OSEF de Me Michu, c'est une personne qui à beaucoup plus de mal à s'adapter.

Entre la vioque qui sait à peine cliquer, le quadra qui lit régulièrement Korben et le petit dernier qui n'en a rien à foutre et qui ira quand même sur le site, ça n'intéressera pas grand monde, donc !

[Stark]

@hugolegrand : Du coup, ça ne serait pas "plus simple" de stocker une Regex ? Comme ça, on gère tous les sous-domaines qu'on veut, on fait des filtres sophistiqués ... Et en plus c'est disponible en JS et en PHP de base ^^
Dans ton schéma, je ne saisi pas trop. C'est une cinématique qui s'applique aux traitement des liens contenus dans la page, ou de l'url de la page en cours ?

@The Datawolf : L'idée étant que si les extensions WordPress et consorts sont suffisamment diffusées, alors ça touchera le public des gens qui l'on installé. Il faudrait voir à prendre contact avec des sites d'actu en informatique. J'vais contacter Marc Rees de PC INpact : un truc comme celui là devrait l'intéresser. Suffit juste de communiquer dessus ...

[Stark]

J'ai profité de ce week-end pour avancer sur le serveur ...

Améliorations

Les améliorations que j'ai apporté :

• Utilisation d'une partie "fixe" pour identifier l'URL d'un site listé et d'une partie RegEx (Expression Régulière) : on vérifiera dans un premier temps si on trouve la partie constante de l'URL (fixe) puis si on trouve une occurrence, on vérifie alors la RegEx associée. Par exemple, dans le cas d'un site internet ayant plusieurs sous domaines associés à des sites liberticides (mais pas tous), et qu'on veut pour des questions de simplicité rassembler le tout sous le même nom/description dans notre base de données, on met en partie fixe "exemple", et en RegEx : "(truc|bidule|chose|machin)\.exemple\.com" qui permet de filtrer les url suivantes : "truc.exemple.com", "chose.exemple.com", "bidule.exemple.com", et "machin.exemple.com". A noter que cette méthode permet de filtrer efficacement les sites internet qui sont identifiés par un répertoire après le nom de domaine (cas des Google Sites par exemple : http://sites.google.com/machin, http://sites.google.com/bidule).
  
• Les URL fixes et RegEx sont propres à UN langage donné. Ça permet d'avoir des règles différentes selon que l'on accède au site franÇais, anglais (il arrive que le formalisme des URL change selon la langue).
  
• On gère la modération : un utilisateur "normal" peut ajouter un site à la BDD, mais il faudra l'approbation d'un modérateur pour que le site soit publié (chaîne de publication).

Schéma de la Base de Données du Serveur

Voici le schéma de la base de données du serveur


Comme vous le noterez, la localisation est au coeur du modèle : en effet, chaque objet a ainsi la possibilité d'avoir son texte traduit dans une ou plusieurs langues, sans qu'on ait à recréer deux objets différents pour deux langues différentes.
Ça ajoute par contre une certaine "lourdeur" au modèle : dès qu'on veut choper un objet, il faut aussi choper les textes traduits qui lui sont associés dans la langue voulue. Mais cela ne devrait pas poser de soucis :

• On affichera jamais toute la base d'un coup ;
  
• Si on doit présenter une page de recherches ou une page avec tous les sites, on s'assurera de limiter le nombre de résultats par page/requête ;
  
• Et la génération des fichiers de données pour les clients n'aura lieu qu'une seule fois par jour (probablement sur un autre processus que celui du serveur pour éviter de tout faire sauter).

Diagramme de classes du Serveur

Concernant le diagramme de classes du serveur, il a lui aussi évolué :



Fichier de données à destination des clients (plugins/extentions)

J'ai déjà commencé à coder une partie des classes du serveur. Je pense boucler Ça d'ici la fin de la semaine qui vient.


Maintenant, la partie qui intéresse très sûrement hugolegrand et kokakiwi : le formalisme des fichiers de données qui seront pompés par les extensions/plugins (que je vais finir par nommer indistinctement "les clients"). J'ai regardé pour faire un truc de faÇon assez efficace, et voici ce que je propose :

• Formats qui seront implémentés "sans soucis" et qui seront "utiles" : JSON (pour JavaScript), CSV/TXT (plus pratique pour PHP), et XML (pour ceux qui ne jurent que par XML) ;
  
• En gros, quelque soit le format, le fichier contiendra "un gros tableau" où chaque ligne correspondra à 1 site dans 1 langue donnée (à cause du fait qu'on peut avoir plusieurs descriptions d'URL pour un même site selon la langue), et où les colonnes seront :
  
  • Langue du site : tel qu'enregistrée dans la BDD
    
  • Nom du site localisé
    
  • Description courte du site localisée
    
  • ID du site internet dans la BDD : servira à construire l'URL du lien "plus d'info"
    
  • Partie Fixe de l'URL
    
  • Partie RegEx de l'URL
    
  • Nom de la catégorie localisée du site
    
  • Liste de tags localisés

Ça veut donc dire que :

• Chaque jour on génère une nouvelle version des fichiers de données.
  
• On génère un fichier par format exportés (XML/JSON/CSV) et par langue enregistrée dans la BDD.
  
• A chaque fichier, on associe son md5sum, afin que le client ne retélécharge le fichier que s'il a été modifié.

Cinématique de l'analyse des URL

Sinon, j'ai mis à jour la cinématique pour les clients pour utiliser les URL fixes et URL RegEx :

Juste une petite précision pour l'algorithme de traitement des URL, tel que le le vois :

• Pour chaque lien trouvé (balise <a>) sur la page :

• On extrait le nom de domaine de l'URL (sans les sous-domaines et l'extension) ;
  
• On regarde dans la liste des "URL fixes" (ouais, j'aurais pu nommer Ça "domainName" mais bon ... ^^) si on trouve ce nom de domaine ;
  
  • Si une occurrence est trouvée : on analyse la RegEx associée ;
    
    • Si Ça match : on a trouvé le site correspondant, on récupère les infos et on décore le lien.
      
    • Sinon, on regarde s'il n'y a pas d'autres occurrences et on les analyses. S'il n'y en a plus, le site n'est pas dans la BDD.
  • Si aucune occurrence n'est trouvée : le site n'est pas dans la BDD.
• S'il reste des liens, on passe au lien suivant. Sinon fin du processus.

Et sinon, donnez moi vos identifiants SourceForge pour que je puisse vous ajouter au projet !
(je mets à jour les documents de spécifications sur le SVN)

[Stark]

Proposition d'Architecture Technique :
 Link2Tag_Architecture_Technique.jpg   90,02 Ko   5 Nombre de téléchargements 

Je me suis dit qu'on était en train de se foutre dedans avec nos histoires de plugins/extensions : en fait, tout le gros du boulot c'est de "parser" une page HTML à la recherches de liens qui matchent à certains filtres. Nous n'avons pas besoin de nous enquiquiner avec une base de données locales, avec des scripts PHP de ouf ...

Ce dont nous avons besoin c'est :

• Une application PHP côté serveur capable de générer un fichier JSON exploitable directement par un script JS ;
  
• Un petit site internet, côté serveur, pour éditer la base de données (PHP/HTML/CSS/JS ... ?) ;
  
• Un script JS côté client capable de :
  
  • Manger le fichier JSON ;
    
  • Récupérer les liens de la page en cours ;
    
  • Vérifier s'ils sont où non dans le tableau du fichier JSON ;
    
  • Décorer les liens le cas échéant.
• Des plugins pour CMS capables de télécharger en local une copie du fichier JSON (pour alléger la charge du serveur du projet), et une copie des script JS, et de les inclure correctement dans le CMS ;
  
• Des extensions pour navigateur capable de télécharger en local une copie du fichier JSON (pour alléger la charge du serveur du projet), et une copie des script JS, et de les inclure correctement dans les pages affichées par le navigateur.

Et c'est tout.
D'ailleurs, pour des raisons de séparation des couches, je préconiserai le découpage suivant pour les scripts JS :

• Un script qui lit le fichier JSON et analyse les liens ;
  
• Un script qui décore les liens (il est appelé par le premier script à chaque lien trouvé, via une fonction qui va bien ou quelque chose du genre).

Comme ça on a un truc 100% générique, 100% maintenance, 100% bien ^^

Qu'en pensez-vous ?

[Stark]

Voici la spécification du fichier d'échange, tel qu'on la vue hier soir avec KokaKiwi.
J'aimerais qu'on boucle ça dans la journée (ce soir maxi) pour qu'on puisse vraiment commencer les développements.

Je mettrais la version PDF sur le SVN ce soir ^^
 Link2Tag_Fichier_d_echange_JSON.png   56,63 Ko   6 Nombre de téléchargements 

Niveau taille, on peut compter entre 300 et 500 octets par site listé dans le fichier. Sachant qu'il faudra éviter de trop déblatérer dans la description brève du site ...
Du coup, pour 1000 sites référencés, on peut compter pour une taille approximative d'entre 300 et 500Ko. C'est tout à fait acceptable.

[hugolegrand]

Ok parfait le fichier Json, par contre à quoi correspond l'array TagsFilter? Je bosse tjrs sur l'extension.

[Stark]

Une idée de KokaKiwi : en gros, pour limiter la quantité de sites internet présents dans le fichier, et pour ajuster les filtres en fonction de ce que veux l'internaute (un peu comme sur AdBlock), on génère plusieurs fichiers qui contiennent les sites internet filtrés selon une liste de tags. Cette liste de tags est dans TagsFilter.

Ça répond du coup à la question du : jusqu'où faut-il aller dans la liste des sites à recensés (puisque l'on pourra choisir).

[Stark]

@hugolegrand : Le gestionnaire d'accès aux données pour les objets du serveur est bientôt terminé. Te devrais l'avoir dans la semaine normalement. Tu pourra ainsi commencer le site internet avec ça.

[hugolegrand]

OKok je me tiens prêt pour le site.