Log in
PloneArticle
Restreindre les meta_types d'un ObjectManager
Interview de Jim Fulton (VF) [Document]
Les origines
Zopera Team (ZT) : Quand avez-vous découvert Python ?
Jim Fulton (JF) : en 1994
ZT : Quand avez-vous décidé de l'utiliser pour la première fois ?
JF : en 1994. Je travaillais sur une implémentation de la base de données /rdb écrite en Perl par Walter Hobbs de la société Rand Corporation. Elle contenait un langage de manipulation de données à base de Perl qui utilisait l'interpréteur de Perl. Je le rendais accessible aux scientifiques de l'institut d'étude géologique américain (USGS). Les scientifiques trouvait la syntaxe de Perl trop étrange ; de plus la bonne volonté de Perl de considérer n'importe quelle chaîne de caractères comme un nombre provoquait de nombreux problèmes pour l'analyse des données. Je cherchais donc un langage léger et orienté objet que je pourrais utiliser pour manipuler des données. J'ai trouvé Python.
ZT : Quand avez-vous décidé de contribuer à son développement ? (Nos google-maniaques n'ont trouvé des informations qu'à partir de 1994 :) )
JF : Je suppose que la véritable première amélioration que j'ai apportée était l'API d'abstraction objet (NDLR: Object Abstraction Layer), sur laquelle j'ai travaillé avec Guido (NDLR : Guido Van Rossum, créateur du langage Python) en 1995. J'avais écrit une extension de Python pour avoir accès à une base de données Ingres et je commençais à travailler sur un outil de génération d'extensions appelant des librairies Fortran. L'API C de Python était très bien, mais il était trop difficile d'écrire des extensions qui soient très souples par rapport aux données qu'on pouvait leur amener.
ZT : Il semblerait que vous ayez été un programmeur Smalltalk,
JF : Oui. Smalltalk est très sympa. J'ai écrit un éditeur de diagrammes visuels pour l'USGS qui utilisait GNU Smalltalk. J'ai aussi passé un peu de temps au sein du comité de normalisation ANSI de Smalltalk.
Il semble qu'il y ait des travaux intéressants qui continuent avec Smalltalk, notamment Squeak (NDLR : http://www.squeak.org ).
ZT : Et il semblerait que vous ayez pensé à faire ce qui est devenu Zope en utilisant Smalltalk. Est-ce vrai ?
JF : Non. :)
ZT : Pourquoi avez-vous choisi Python finalement ?
JF : J'étais déjà converti à Python à ce moment là. ;)
ZT : Si ce choix était à faire aujourd'hui, ça serait Python ou auriez-vous essayé quelque chose en relation avec Smalltalk (comme Squeak ou GNU Smalltalk)
JF : J'aurais presque certainement choisi Python, pour plusieurs raisons, entre autres :
La syntaxe de Python est beaucoup plus propre et simple à comprendre.
Je préfère l'héritage multiple. Bien que l'héritage multiple puisse être utilisé à outrance, il permet de simplifier dans de nombreux cas un développement intégrant de multiples frameworks.
Il y avait beaucoup d'autres raisons qui font que je n'aurais même pas considéré Smalltalk en 96, comme l'absence d'une implémentation portable solide et peu onéreuse de Smalltalk, ou sa faible adéquation pour des applications non graphiques. Je n'ai pas vraiment continué dans la direction de Smalltalk. Squeak est vraiment intéressant et la communauté Smalltalk a probablement fait beaucoup de progrès dans d'autres domaines.
Je pense définitivement que Python peut apprendre de Smalltalk. Je m'occupe de ma propre partie. ;)
Zope Corp
ZT : Quand et comment avez-vous rencontré Paul Everitt ?
JF : Je l'ai rencontré au premier atelier Python, "Spam I". Nous avons gardé le contact à travers la Python Software Activity (PSA).
ZT : Quelles raisons vous ont poussé à rejoindre l'aventure Digital Creations (devenue depuis Zope Corporation) ?
JF : Bien, j'avais travaillé pour l'USGS depuis quelques temps. L'USGS est un organisme formidable, mais pour diverses raisons, j'avais décidé qu'il était temps de faire quelque chose de différent. Et c'est clair, Digital Creations était différent. 8v]
ZT : Combien y a t'il d'employés chez Zope Corp à l'heure actuelle ?
JF : 27, dont la plupart sont ingénieurs.
ZT : Combien d'entre eux travaillent sur le coeur de Zope ?
JF : Tous les ingénieurs.
ZT : Et combien d'entre eux travaillent en tant que consultants auprès de vos client directs ?
JF : Tous les ingénieurs.
Vraiment, la meilleure façon d'améliorer un outil est de l'utiliser. Il est certain que tout ce que nous faisons pour un client ne va pas dans le coeur de Zope, mais nous améliorons souvent le coeur de Zope pour le faire mieux fonctionner chez nos clients.
ZT : Combien d'heures doivent-ils vous vénérer durant une journée ? ;-)
JF : Aucune, j'espère.
Zope & Business
ZT : Avez-vous une vision du futur du développement web, que vous poursuivez depuis plusieurs années, ou essayez vous de surveiller les standards de l'industrie et d'en garder le meilleur ?
JF : Je suis un inconditionnel de l'objet, et avec Zope il a toujours été question d'utiliser la puissance de la technologie objet et de Python pour apporter des solution web aux problèmes complexes, et le plus simplement possible.
Bien sur, nous suivons les standards de l’industrie. Nous accordons plus d’importance aux standards utiles à nos clients ou qui nous facilitent la vie. Cela est vrai également, bien sûr, pour la communauté Zope.
ZT : Nous savons que Zope gagne en fonctionnalités grâce aux développements faits pour des clients (ZOracleDA). Mais n'est-il pas frustrant pour un directeur technique de ne pas pouvoir affecter des priorités et des ressources en fonction de ses idées plutôt qu'en fonction des demandes des clients ?
JF : Ça peut être frustrant, mais d'un autre côté il est souvent plus frustrant de développer des logiciels dans le vide. Heureusement, Zope Corporation et la communauté Zope au sens large ont la créativité pour faire avancer le produit en apportant des solutions qui correspondent aux besoins des clients, ou parfois en les anticipant.
Beaucoup de bonnes idées ont été développées dans le Content Management Framework (CMF) tout en résolvant des problèmes très spécifiques de clients. Je pense que le CMF a eu plus de succès que le précédent effort de Portal Toolkit (PTK), en partie, car il a été dicté par des besoins spécifiques de clients. Le CMF est la pierre angulaire de nos projets de conseil.
ZT : Vous ressemblez plus à une société de conseil qui adapte son logiciel sans idée directrice qu'à un éditeur de logiciels, n'est-ce pas ? Est-ce que vous n'avez pas ouvert vos sources pour combler ce manque ?
JF : Non. Non.
Notre activité de conseil est construite autour de Zope, et non l'inverse. Zope est une plate-forme qui apporte de réels bénéfices pour nos clients et qui nous permet de monter des solutions en une fraction du temps que nécessiterait d'autres approches. L'ouverture du code source de Zope était la meilleure façon de renforcer la plate-forme, qui, en retour, renforçait notre activité de conseil.
ZT : Dans vos réponses à appels d'offres, utilisez vous des composants écrits par la communauté ?
JF : Oui.
ZT : Comment vos clients l'apprécient ils ?
JF : Ils réalisent que la réutilisation diminue leurs coûts et les risques.
ZT : Y a-t-il des composants que vous avez écrits pour des clients et qui n'ont jamais été disponibles en open source ?
JF : Bien sûr. Certains composants sont très spécifiques à un client, ou recèlent parfois des technologies ou des idées dont seul le client a la propriété.
De temps en temps, nous créons aussi des technologies que nous ne rendons pas disponibles en open source, mais dont les sources sont partagées avec nos clients et d'autres testeurs.
Le futur de Zope
ZT : Qu'en est-il de l'internationalisation (i18n) de l'interface de gestion de Zope (ZMI) ?
JF : Zope 3 incorporera le support de l'i18n. Tout le code du coeur de Zope 3 sera internationalisé.
ZT : Que pensez vous de l'interoperabilité J2EE au sein de Zope ?
JF : Zope peut inter-opérer à l'heure actuelle, dans une certaine mesure, avec J2EE. Nous avons l'expérience d'une intégration avec BEA à travers une base de données Oracle partagée.
Dès que Jython 2.2 (NDLR : Portage de Python sur la machine virtuelle Java, jython.org ) sera disponible, je m'attends à ce qu'il y ait un effort de la communauté pour porter Zope 3 sur Jython. J'ai prévu d'aider activement cet effort. Faire tourner Zope sur Jython devrait dégager un certain nombre d'opportunités pour une plus grande intégration avec J2EE.
Nous avons aussi commencé un effort pour intégrer Zope à des gestionnaires de transaction externes, ce qui devrait nous permettre de coordonner des transactions avec des applications J2EE.
Une autre option pour l'intégration avec J2EE est CORBA. Malheureusement, J2EE nécessite la fonctionnalité d'appels de méthodes CORBA par valeur, ce qui a longtemps manqué au support de CORBA dans Python. L'ouverture récente du code source de Fnorb devrait apporter une opportunité pour régler ce problème. (Indice indice ;)
ZT : Et Zope en tant que serveur SOAP ?
JF : Il s'agit vraiment de quelque chose qui nous intéresse. Voyez, par exemple le wiki suivant :
http://dev.zope.org/Wikis/DevSite/Projects/WebServicesForZope.
ZT : Zope et XML : qu'est-il prévu ? Est-ce que Zope se comportera dans le futur comme un serveur XML pour de grandes bases de données ? Qu'en est-il de l'implémentation des standards du W3C : XSLT, XPATH, XQUERY ?
JF : La communauté Zope a pris le pas en général sur les technologies XML. Il y a beaucoup de travaux intéressants en cours, dont la gestion du XML et le support pour des standards comme RDF, XSLT et XPATH.
ZT : Quand aura-t-on un langage d'interrogation au sein de Zope, similaire à OQL ?
JF : Bien, nous avons en ce moment Python et les langages d'interrogation des catalogues. Ceci suffit à beaucoup de besoins.
Stephan Richter travaille sur le projet ZOQL, qui cherche à apporter à Zope un langage d'interrogation similaire à SQL et de manipulation d'objets. Cela devrait être génial pour des traitements spécifiques.
ZT : Quel échéance avez-vous prévu pour Zope 3 ?
JF : Zope 3 sera largement un effort de la communauté, donc je ne peux faire aucune promesse, cependant je suis très confiant dans le fait que Zope 3 sortira sous une forme utilisable cet été.
ZT : Quelle est la fonctionnalité la plus excitante que vous voudriez voir dans Zope 3 ?
JF : Il y en a tellement, c'est difficile de choisir, entre :
l'architecture par composants et le nouveau modèle de développement
l'intégration du CMF
le support intégré de l'internationalisation
la séparation du code et de sa configuration
le nouveau système de catalogue et les nouvelles modèles de méta-données
pour en nommer quelques uns, mais je dois dire que je suis excité le plus par la nouvelle architecture par composants.
(Merci à Kamon et BenDeck pour l'aide à la transcription et à la traduction de cette interview)
Photo de Jim Fulton propriété de lwn.net. Source : http://lwn.net/2001/features/oreilly2001/
Re: Interview de Jim Fulton (VF)