Alex G. a écrit 655 commentaires

De ce que j'ai compris (je ne connais qu'un peu), la notion d'interface en Zope est à la base de la notion d'architecture à base composant.
En gros, ton code demande un objet qui implémente une interface et hop Zope te sort l'objet qui va bien suivant le contexte. C'est une méthode préféré à celle qui consisterai à donner un composant par "nom", l'interface étant censé décrire sémantiquement les propriétés de l'objets attendu. Autrement dit, c'est le contrat que doit satisfaire l'objet qui sera fournit par Zope lorsque l'application demandera tel composant.
Ceci permet de changer un composant par les fichiers de configuration (mais aussi depuis le code) et de remplacer un composant dans le futur.

Et effectivement, le modèle qui consiste à dire que chaque page est un objet est séduisant, mais en pratique ça sert à quoi ?
Est-ce qu'on peut par exemple avoir une sortie pdf ou odf de l'objet automatiquement puisque c'est simplement un autre affichage de la page résultat ?

Ouip, mais plus précisément c'est le fait d'avoir des vues et l'adaptation qui le permettent. Si j'ai bien compris, tu fait un objet qui est une vue d'un type objet (adapte l'objet) pour une interface, par exemple "vue PDF". Si l'on demande la vue PDF de l'objet, Zope utilise ton adaptater avec l'objet PDF pour faire le PDF.
Ceci peut permettre d'avoir un adaptater PDF général par exemple pour les objets qui répondent à l'interface "objet texte" et de spécialiser l'adaptateur (par héritage par exemple) pour les objets "objet texte avec plan".

Le fait de n'avoir que des objets te permet surtout de tout stocker de manière homogène (ZODB), de pouvoir utiliser l'héritage, de faire des tests unitaires....

Je pense que ta critique est un peu légère.
Gecko est un moteur plus vieux que khtml et a surement des révisions qui ne sont pas simple à mener.
Heureusement qu'aucun logiciel n'est parfait (sinon on n'aurais plus de boulot) et avancer c'est décider (donc choisir une route et pas une autre).
Le fait que Gecko n'intègre pas vite ACID2 est un choix (ne pas pénaliser tout par la refonte de cet aspect); mais ne veuc pas dire que c'est nul.
Je pense que quelque part Gecko n'a pas besoin de démontrer encore que c'est un moteur de rendu valable (même si ce n'est pas forcément le meilleur). Il n'y a pas de la place que pour 'le meilleur' (sur quels critères ?) dans ce monde.

Je plussois.
Autant j'étais d'accords avec les avantages sus-cités de Java, autant dire que Python n'apporte rien est mal connaître ce langage.
Pour citer deux points où Java pèche par conception (à mon avis):
- flexibilité/robustesse des interfaces grâce aux arguments par défauts et passage de paramètres par mot clé, arguments dictionnaires
- expressivité grâce à la surcharge de tous les opérateurs (même les getter/setter, iterateur....). Pas besoin de faire du bytecode pour

Là où il faut 10 000 lignes de Java il en faut souvent 3 000 en Python et c'est autant de gagné en maintenance

Je pense que Nuxeo gagne dans le passage seulement parcequ'ils touchaient effectivement des limites de leur plateforme actuelle et auraient dû développer certains composant de base par eux même en Java ils peuvent réutiliser l'énorme travail de Apache - Jboss.
Perso je crois que le coup de grâce reste la pression de leur clients pour avoir du JAVA. En effet je me demande si à long termes Nuxeo va vraiment gagner (quand ils se trouverons limittés par les composants actuels).

Ouip à l'époque j'ai postulé mais mon profil n'était pas celui recherché (trop d'études, trop d'expérience). J'étais prêt à négocier mais il ne m'en ont pas laissé le temps. Après un échange par mail il ne m'ont plus jamais répondu.

Pareil, je ferais volontier du Python mais je ne vois rien sur Lyon autour de ça.

Bonjour,
Perso je comprends tout à fait le choix de Nuxeo.
Ceci ne m'empêche pas de pleurer la perte d'une entreprise qui utilisait Python avec brio.
Je suis développeur Java et j'aimerais plutôt trouver un job python tellement je trouve ce language (et sa dynamique de communauté) plus attrayant.
Je comprends bien que vous aviez vraiment atteint des limittes de ZODB mais sur ce point, il suffisait d'utiliser une base SQL plutôt que ZODB pour certains objets.
Je suis peiné d'une décision qui me semble avant tout marketing En effet j'ai vraiment l'impression qu'il faut surtout rassurer les décideurs des administrations qui on fait le choix de java et qui n'ont pas confiance dans leur développeurs pour intégrer des choses nouvelles.

Sans parler de changer la licence du kernel en entier, les nouvelles contributions ne pourraient-elles pas être sous licence GPL v3 (pour peu que celle-ci soit compatible GPL v2) Ainsi des gros morceaux nouvellement développés pourraient se trouver en GPL v3.

Personnellement je trouve que le sujet est dur à trancher (c'est un peu comme faut-il porter des logiciels libre sous windows) : soit tu implémente un DRM libre et tu permet à plus d'utilisateurs de venir à Linux, soit tu ne les implémentes pas et tu favorise les oeuvres en CC et Art Libre mais peux-être pour moins d'utilisateurs.
Après tout quand Stallman à mis la libc sous LGPL c'était pour permettre de faire des logiciels propriétaires sur le système Gnu.
Mon choix irait plutôt vers implémenter les DRM libres, car je pense que CC et Art Libre s'imposerons si les DRM limittent trop l'intérêt des musiques copyrightés.
Mais bon, je conviens largement que ça se discute.

Je vois la chose différement : le programme dont tu as le source implémente les DRM. Si tu fais une modif du programme pour enlever la protection et lire tes fichiers en outrepassant les DRM tu te mets hors la loi (par le fait que tu as modifié le programme pour outrepasser les DRM). Le programme lui reste libre et tu es libre de le modifier (mais pas d'en faire une chose qui outrepasse tes droits).
Donc moi je dis qu'une implémentation libre de DRM est possible. Mais bien sur elle facilite la vie aux éventuels personnes qui veulent briser les verrous (mais ça il le ferrons surement de toute façon).

Tout d'abord bravo, il faut absolument développer des PGI libre.
De plus je pense que la solution de l'hébergement / maintenance / sauvegarde externalisée est vraiment une offre séduisante pour une PME et qui permet un ROI (via le service) sur un produit libre.

Ma question en quoi est developpé le PGI ?
Y-a-t'il un accès cvs/svn ?

J'allais répondre à ton premier post que effectivement moi je suis très heureux de voir une application métier basée sur XUL. En effet il s'agit là d'une application propre à l'entreprise elle fait donc le choix de XUL. De plus XUL est vraiment multiplatteforme et est tout de même plus facile à manipuler que du HTML plein de Javascript (très lent sur les petites machines genre céleron).

Une question qui va paraitre idiote. Je n'ai regardé que très rapidement la présentation (donc je ne veux pas être insultant). Mais peut on voir ça en gros comme l'association d'un moteur de template et d'un modélisateur UML ?

ça va me permettre d'attaquer les slides sereinement.

Vilain Pirate va !

Oui mais les fruits de ton arbre qui tombent sur le trotoire sont à tous.
Perso je porterais plutôt réclamation contre le propriétaire du WIFI qui pollue l'espace publique avec son réseau ;-)
Plus sérieux je crois que si tu ne chiffre pas du tout ton réseau il est difficile pour moi de savoir que je ne devrais pas y aller.

Merci ! Parfait.

Salut
J'ai essayé le jeu pour voir, ça à l'air effectivement intéressant. Par contre je me suis bloqué au tableau des pieuvres qui est très difficile comparé au début.
En fait j'aurais bien aimé une petite vidéo qui montre comment on fait. Ca éviterais de se décourager.

Encore une fois, ce que je vais dire va parraitre bizzare mais j'ai le sentiment que ce n'est pas indéfendable.
La loi dit qu'il ne faut pas divulguer les moyens de contournement des DRM. Or une implémentation GPL des DRM ne donne pas les moyens de countournement en elle même (c'est la modification du code qui donne ce moyen).
En fait le GPL remet les DRM à leur place : c'est un contrat moral auquel j'obéis de mon plein gré (et en vue de respecter la loi). Le DRM est une justification que j'ai joué le jeu. Ce n'est pas l'occasion pour quelqu'un de l'extérieur de venir faire la police chez moi.
De même pour trusted computing, ce qui compte c'est une chaine de confiance mais en GPL c'est une chaine de confiance seulement pour l'utilisateur (personne ne peut modifier mon système).
Encore une fois il s'agit là d'une vision optimiste. Toutefois je me dis qu'il y aurai intérêt à développer une telle vision pour voir si c'est défendable devant la loi et quels sont les points d'appuis que l'on a maintenant que la loi est passée.

C'est de ça que je ne suis pas sûr justement. La loi dit qu'il est interdit de divulguer le moyen de contourner les DRM, ou de le faire à des fin de contournement. Quand tu implémente les DRM même en libre, tu ne donne pas le moyen de contournement (qui pour un non technicien est loin d'être exposé de manière évidente dans le code) et tu ne cherches pas à faire ça (tu cherche à implémenter les DRM). Grosso Modo c'est celui qui fournit un patch à ton logiciel pour enlever les DRM qui est fautif (tout comme un cracker sur un logiciel propriétaire). En pratique je pense que ça peut marcher pas trop mal (même s'il y a effectivement un tranche de gens qui utilisera un logiciel patché, comme aujourd'hui de toute façon).
J'ai l'impression que l'idée n'est pas de lutter fortement contre les pirates mais de ne pas permettre que Mr tout le monde n'est pas trop facilement les outils qui lui permettent de se passer des DRM, ceci afin de pouvoir servir de l'achat au nombre d'écoute et autre conneries..
Bon je te l'accorde je suis peut-être super optimiste.

Petit à petit je me demande tout de même si les distributeurs ne pourrons pas se satisfaire d'un logiciel libre implémentant les DRM (mais il faudra surement qu'il soient au début contraint par la loi pour interropérabilité).
Après tout ce qui intéresse les distributeurs c'est que ça marche pour 90% des cas. Je ne crois pas que le but des DRM est d'avoir 0% de piratage mais que l'on puisse punir plus sévèrement celui qui pirate (et surtout distribue le logiciel pour pirater), l'ayant fait sciemment.

Si on admet l'hypothèse ci dessus, après on peut refuser les DRM pour d'autres raisons plus philosophique (comme le propose Stallman, et j'adhère assez à ce principe), comme le fait qu'ils recraient la rareté artificiellement sans avantage pour le consomateur (bien au contraire), que la culture mérite d'être protégée d'un commerce à outrance, etc...
Bref ça devient un peu comme utiliser linux avec ou sans logiciels libre.

Mon sentiment est qu'un tel discour est de toute façon mieux que rien. Puisqu'il y a une belle déclaration, il permettra au moins de rappeler les intentions du législateur lorsque la loi a été faite et cet "esprit de la loi" ne peut qu'avoir une influence positive pour la jurisprudence.
C'est surement léger à coté du texte de loi. Ceci dit, y-a-t'il quelqu'un qui a déjà réussi à faire une analyse détaillé du texte et est-elle si pessimiste ? Au vu des citations plus haut, je doute qu'il soit aisé de comprendre vraiment si c'est si catastrophique et je me demande s'il ne faut pas attendre les premières jurisprudences. Par exemple mon impression à lire les extrait est que si je fais un logiciel libre qui respecte l'intention des DRM (même en laissant les sources à disposition), je ne suis pas attaquable. Seul celui qui modifie les sources pour passer outre les DRM ou fournit un tel patch est attaquable. C'est peut-être acceptable.

<opinion>
Personnellement je suis plutôt contre le piratage des oeuvres commerciales dans la mesure où il freine le développement des autres modes de diffusion (genre jamendo, magnatune). Par contre je considère l'interopérabilité comme très importante.
</opinion>

Oui mais je ne pense pas qu'il pourrons refuser à une association ce droit

Là où je ne suis pas d'accord avec toi c'est que les benef ce n'est pas tout. Dans les 'frais' il faut voir qui est rénuméré.
Moi ce qui me gène dans le système actuel c'est que la musique sert de preéexte à nourir surtout des commerciaux et directeur (quel est le salaire de ces derniers) au lieu de rénumérer l'artiste. Ceci pour un travail qui aujourd'hui (avec l'avènement des réseaux) devrait être minoritaire.
C'est ça le problème. La marge de VU est peut-être raisonnable (bien que 10% je trouve ça énorme) mais les 'frais' vont dans les poches de qui ?
Le pire pour nous est que ces gens portent à une industrialisation du secteur (ça permet de faire plus de benef et de surtout de garder le controlle du marché) au détriment de la qualité (qui est plus la fibre des artistes).

Ca c'est un problème, tu as aussi le problème de l'intonnation qui ne semble pas si important mais qui l'est en fait vraiment.

+1 pour les graphe à la place des arbres

Une autre chose que j'aimerais qui soit ajouté à freemind : un énorme ensemble de petites icônes avec des tags pour tout illustrer.