Cédric Krier a écrit 118 commentaires

Il y a aussi d'autres solutions plus proche comme Tryton pour laquelle des outils de migration existent.

Évidement que c'est mieux pour lui que tu fasse des extensions libres et lui des propriétaires que l'inverse.

Depuis son changement de licence, c'est un développement Open Core qui est adopté par la société éditrice. La plus parts des améliorations présentés ici font en faite partie de l'édition Enteprise.

Le lien vers la démo du client web est multilingue, ce serait bien si quelqu'un pouvait le mettre en anglais au lieu d'espagnol.

Il sera possible de suivre la conférence en ligne sur http://tul2014.tryton.org/360-live/

Oui mais nginx sera retiré de la futur version 5.7 au profit d'un nouveau serveur httpd(8) basé sur relayd(8).

La version 10.0.12 de MariaDB est présente dans le ports.
http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/databases/mariadb/

Voici l'explication pour Kerberos : http://undeadly.org/cgi?action=article&sid=20140425065910

Soit la suppression est due au fait qu'un meilleur solution existe (généralement en terme de sécurité) comme pour rsh vs ssh.
Soit c'est des logiciels qui n'étaient pas développés par OpenBSD et donc ils sont sorties du système de base en faveur d'un « package ».

La version web du client a aussi bien avancée même si elle n'est pas encore prête pour une utilisation en production.

C'est basé sur CKEditor

Il faut remarqué qu'une partie de cette campagne concerne du développement propriétaire. En effet les themes développés ne seront pas libre (voir la FAQ de la campagne).

https://linuxfr.org/news/sortie-de-tryton-3-2

Aux dernières nouvelles, la politique de migration n'a pas changée, c'est-à-dire qu'elle n'est pas développée de manière ouverte. Mais il semblerait qu'openerp/odoo ne vends plus le service de migration seul, la page des prix ne parlent que d'abonnement au service d'hébergement.

Correction:
* Je n'ai pas dit "ne correspondait pas à ses exigences" mais "ne correspondait pas à mes besoins".
* L'objectif du projet flask-tryton est juste de permettre l'utilisation de Tryton dans une application Flask.

Nereid est monolithique dans le sens où son usage n'est possible que pour les cas d'utilisations restreints déjà prévues par l'auteur (gestion des utilisateurs, de la langue, du multi-société, composition des pages/URLs, etc.).
Pour les modules, en effet il se base sur le mécanisme de Tryton mais je pense personnellement qu'il ne convient pas pour répondre aux demandes variées de création de site web car la modularité ne permet pas de modifier l'architecture.
À propose des modules, le webshop d'après mon analyse est trop simple pour gérer la diversité des cas. Le module de projet est basé sur une simplification de celui de Tryton.

En fait, c'est déjà utilisable. On l'utilise sur notre site web.
Par rapport à Nereid, on profite de tout l'éco-système de Flask qui est bien assez riche. Alors oui, ça reste une boîte à outils et pas un logiciel clés en main mais personnellement ça répond bien mieux à mes besoins.

De plus que ce module utilise MD5 qui n'est plus vraiment considéré comme sûr.

Ça n'a jamais été corrigé et il y a une forte résistance des mainteneurs pour garder cette «fonctionnalité».
Voici le code de la version de développement où le mot de passe est écrit en clair dans la base de données:
https://bazaar.launchpad.net/~openerp/openobject-server/trunk/view/head:/openerp/addons/base/res/res_users.py#L125

On n'est pas vraiment contre un changement de format mais il faut que ça apporte un plus sans retirer de fonctionnalités. Par exemple, on parse les fichiers XML avec un parser SAX pour limiter la consommation mémoire car il y a des fichiers assez gros (1.3M pour country.xml).

C'est sur ce point qu'on ne se comprend pas. python-sql n'est pas un couche d'abstraction de BD. C'est juste une librairie pour générer des requêtes SQL en les écrivant explicitement avec des objet python plutôt que de manipuler des strings.
python-sql ne connait rien de la BD sur la quelle la requête va être exécutée, d’ailleurs la même requête peut être utilisée pour différentes BD tant qu'on utilise la bonne Flavor de contexte. On se repose entièrement sur les librairies de connexion pour faire leur boulot. S'il y a des manques pour l'une d'entre elle, c'est celle-ci qu'il faut améliorer (pour info, psycopg2 gère les datetime avec fuseau horaire).

Oui, une telle faute de frappe est détectée et lève une exception:

AttributeError: 'Select' object has no attribute 'wehre'

Sauf que par exemple ça ne gère pas les fractions de seconde ni les fuseaux horaires.
Avec une bonne couche d'abstraction, si j'ai un datetime avec un fuseau horaire et des microsecondes et que je le sauve dans une base PostgreSQL, je ne perds pas d'information.

Ça c'est un manquement dans la PEP. Bien que perso, je pense qu'il est préférable de stocker tout en UTC.
De plus, tous les SGDB ne supportent pas les fuseaux horaires par example SQLite.

Ben oui, mais qui écrit / invoque l'adaptateur ? Si c'est ta bibliothèque, alors elle n'ignore plus le type de BD utilisé :-) Si c'est l'utilisateur, ta bibliothèque est sous-optimale par rapport à d'autres solutions.

Je ne trouve pas que ce soit le rôle de la librairie de faire ces choix.
Par exemple, pour Tryton, on a des adaptateurs spécifiques pour les float et Decimal sous PostgreSQL.

C'est pris en charge par la PEP249: http://www.python.org/dev/peps/pep-0249/#type-objects-and-constructors
Et donc il suffit d'utiliser l'expression Literal avec le bon type.
De plus la plupart des librairies de connexion ont des méthodes pour enregistrer des adaptateurs:

• http://initd.org/psycopg/docs/extensions.html#psycopg2.extensions.register_adapter
• http://docs.python.org/2/library/sqlite3.html#sqlite3.register_adapter
• http://mysql-python.sourceforge.net/MySQLdb-1.2.2/public/MySQLdb.converters-module.html

Sauf que c'est pas très performant parce qu'il faut aller lire la définition via le SGDB et plus comme on ne veut dépendre d'aucun SGDB en particulier.