darkBlog

Me voilà de retour dans ma chambre d'hôtel. Je suis ereinté, fatigué. Déjà parce que ceux qui me connaissent savent que c'est mon état permanent, ensuite à cause du décalage horaire, et enfin par la difficulté liée à l'attention permanente requise pour la compréhension d'une journée de sessions techniques, auxquelles on ajoute l'effort de traduction. Et aussi parce que ça s'est terminé sur une réception bien arrosée (à la Stella, sacrilège).

A part ça, la journée s'est bien passée. A ma grande surprise, je n'ai pas eu trop de difficulté pour comprendre les conférences. Je ne peux pas, en toute objectivité, dresser un bilan aussi positif des rares moments où j'ai pris la parole. Ce qui curieusement me rappelle les propos de ma prof' d'anglais de 1ère année de DUT, qui étaient peu ou prou : "l'objectif de mes cours n'est pas que vous parliez un anglais parfait, mais que vous arriviez à comprendre ce qu'on vous dit, et à l'inverse à vous faire comprendre.". Je pense qu'elle serait fière de moi aujourd'hui.

Pour rentrer dans le vif du sujet, je suis assez perplexe à l'issue de cette première journée. Non pas par la qualité des sessions ou de l'organisation (d'ailleurs, une des meilleures idées qu'ils ont eu est de commencer par filer à chaque personne une clé USB de 512 Mo avec tous les slides, exemples de code et programmes qui ont et vont être évoqués sur ces 2 jours & demi), mais plutôt par ce que j'y ai vu.

Le programme étant très chargé, pour la grande majorité des créneaux, 3 sessions avaient lieu en parallèle. Je n'ai , forcément et malheureusement, pu assister qu'à une conférence à la fois. En voici mes impressions.

Read next

Pour résoudre les problèmes liés aux requêtes AJAX sur différents serveurs/domaines avec Domino, Philippe GAUVIN nous a récemment proposé un agent de proxy en Java. Je me suis inspiré de son travail pour le doter de nouvelles fonctionnalités, et je vous en propose ainsi une version "améliorée"¹ :

• Transfert des cookies client -> serveur cible (nécessaire pour l'authentification sur le serveur cible, dans le cadre d'un environnement SSO, par exemple).
• Transfert des cookies serveur cible -> client (si jamais le serveur cible pose un cookie sur le client. Peut ne pas fonctionner si le domaine du cookie est trop restreint).
• Transfert du langage du navigateur (entête HTTP Accept-Language, dans le cadre d'applications multilingues basées sur ce critère).
• Transfert du type MIME retourné par le serveur cible vers le client (bon, j'avoue, celui-là je ne suis pas persuadé qu'il serve à grand chose).
• Réinitialisation systématique du cache (tant coté client que serveur cible).

Vous pouvez le téléchopper ici : DominoProxy.java. La version que je vous propose a été développée pour du Domino R5 (soit JDK 1.1.8 !), mais devrait fonctionner sans problème sur les versions plus récentes de Domino, ou à de menues adaptations près.

1 : N'y voyez pas là un dénigrement de ma part de son travail, hein, loin de là.

Domino R6 a introduit le support de WebDAV il y a maintenant plus de 3 ans, et j'ai l'impression que cette fonctionnalité, fort pratique au demeurant, est finalement assez méconnue des développeurs. Oh, je ne prétends pas à la connaissance ultime, et l'ai d'ailleurs découvert récemment et tout à fait par hasard en me balladant dans Lotus Administrator, mais je reste surpris de ne pas en avoir entendu parler auparavant.

Cette fonctionnalité permet aux développeurs d'accéder aux ressources partagées (images, fichiers, feuilles de style, etc) d'une base via un partage WebDAV, ce qui s'avère extrêmement pratique à l'usage, tant pour ajouter des librairies conséquentes (par exemple YUI et sa centaine de fichiers et vingtaine de répertoires) que pour éditer en live des scripts ou des feuilles de style, plutôt que de les exporter-éditer-rafraîchir à la chaine (et d'y inclure au passage le bon paquet d'erreurs de renommage qui va avec).

Sans WebDAV, la gestion des fichiers dans une base est
aussi agréable qu'une séance chez le dentiste

Avec WebDAV, on est directement propulsé dans le XXI^e siècle¹ !

Curieusement, la documentation disponible est assez floue et succinte (voir Setting up WebDAV et Enabling WebDAV ), et les questions à ce sujet se comptent par dizaines dans le forum Domino R6 et R7 (16 dizaines, pour être précis). Alors comme j'ai pas mal galéré pour mettre en place WebDAV de mon coté, voici la marche à suivre que j'ai retenue :

1. Dans le document de configuration du serveur, activer l'utilisation des documents de site:

   

2. Dans la section Web » Internet Sites, créer un nouveau document de site (ex : webdav.monserveur.mondomaine), activer toutes les méthodes HTTP, activer Webdav, et désactiver les sessions HTTP :

   

   

3. Relancer la tâche HTTP (tell http restart)
4. Pour les bases à accéder via webdav, spécifier dans leurs ACL respectives l'accès designer ou manager à l'utilisateur qui sera utilisé pour la connexion. Spécifier également pour niveau d'accès internet maximum : designer (par défaut c'est editor).

   

5. Indiquer également un serveur d'administration (ie : le serveur webdav).

   

6. Enfin, activer le design locking sur la base.

   

7. Accéder au partage WebDAV via une URL du type : http://webdav.monserveur.mondomaine/mabase.nsf$files (notez le symbole 'dollar').

Pour rappel, le WebDAV dans l'explorer de Windows XP fonctionne mal, et je vous invite à utiliser un client du type Netdrive. Et pour terminer, quelques considérations issues de mon expérience personnelle, à ajouter à celles de la documentation liée plus haut :

• Utilisez des utilisateurs dans les ACL et non des groupes. Cela fonctionne peut-être, mais de mon côté tous mes essais se sont avérés infructueux.
• Vous ne pouvez utiliser WebDAV que sur des bases, pas des templates.

Edit + 2 mois : Pour régler les problèmes d'authentification que j'ai évoqué dans ce billet, une règle importante à suivre : ne pas mettre la base à la racine du serveur (/data), mais dans un sous-répertoire. Merci Jesper Kiaer.

1 : ah, on me signale dans mon oreillettes qu'on y est depuis 6 ans.