Des nouvelles de Lightroom 4.1 ?

[Reflexnumerick]

j'ai LR 3.6. LR 4 ça rame vraiment plus en comparaison ? mon outil informatique : Intel Core 2 Quad Q8200, 8 go mémoire.

[Pat91]

Pat parle de soupçons sans preuve .....

Ce n'est pas tout à fait ça. Je peux clairement prouver qu'Adobe ne fait pas de tests de régression ou ne les fait pas correctement. Ce point ne mérite même pas une discussion tellement c'est évident. Je peux également montrer, dans une discussion technique avec un développeur (ce qui n'a pas lieu d'être ici), que LR ne se comporte pas de manière orthodoxe. J'ai des idées sur ce qui provoque ces dysfonctionnements (et ces lenteurs) et c'est ça que je ne peux pas démontrer, n'ayant accès ni au code, ni à des documents architecturaux précis.

Par exemple : j'ai lu que 40% du code de LR est écrit en LUA, langage interprété (le reste, dont très probablement le moteur de dématriçage, est écrit en C/C++). C'est un choix très surprenant pour un programme fondamentalement orienté calcul. Même en admettant que les parties critiques soient écrites en C/C++, on voit mal ce qu'un langage de scripting interprété vient faire dans le décor. Ceux qui disposent d'une configuration puissante sont naturellement moins affectés. Cela peut expliquer les différences perçues par les utilisateurs.

Autre exemple : le choix du moteur de base de données. Il y a des solutions plus performantes (et de loin) que SQLite. Là aussi, le choix est surprenant, surtout quand on ne voit pas comment expliquer les différences de performances entre LR et Camera RAW autrement que par les tâches supplémentaires effectuées en parallèle par LR : la mise à jour permanente du catalogue et le recalcul des aperçus.

Imaginer qu'Adobe ai pu commettre un choix déraisonné sur ...on ne sait pas quoi finalement me parait vraiment osé.

Si un éditeur de logiciel est capable de bâcler la partie assurance qualité (c'est le cas pour LR et c'est probablement un choix délibéré pour cause politique/économique), il est également capable de faire des choix politiques peu judicieux en termes d'architecture, éventuellement contre l'avis des développeurs - et j'ai eu sur ce point quelques retours très clairs d'un des développeurs de l'équipe lors d'échanges privés). Donc je n'ose rien du tout, je parle d'expérience, ayant vécu des situations similaires chez d'autres "grands" éditeurs ou chez des sociétés de service travaillant pour eux.

On en revient toujours au même problème : il est naïf de croire qu'une société de renom fait systématiquement des choix basés sur le bon sens technique. Rien n'est plus faux car ce sont le calendrier et les financiers qui de nos jours, dictent unilatéralement leur loi aux ingénieurs. Chez Adobe comme chez beaucoup d'autres.

[Pat91]

Pourquoi n'essaierais tu pas d'en parler aux développeurs, avec un descriptif le plus précis possible ?

J'ai déjà eu ce type d'échanges en privé avec un des développeurs de LR - non, je ne dirai pas qui - et il avait à l'époque parfaitement reçu mes arguments et remarques. J'ai cependant cru comprendre (je dois encore avoir ses messages en archive) qu'il y avait quelques tiraillements entre ce que les développeurs souhaiteraient faire (ou défaire) et le management qui leur imposait certains choix dictés par des considérations non techniques.

Il y a dans ce monde du logiciel des relations complexes entre 4 groupes d'acteurs:

- les utilisateurs : ils vivent des expériences diverses, sont satisfaits ou non, ne peuvent en général que constater (ou non) les problèmes.
- les développeurs : qui souvent voudraient être libres de leurs choix techniques et ne le sont pas en pratique.
- les marketeurs : qui ne sont motivés que par les profits et ne se préoccupent de qualité que lorsque sa dérive peut affecter ceux-ci.
- les évangélistes : qui font en général un bon travail de soutien aux utilisateurs mais s'interposent quand le problème n'est pas lié à une mauvaise pratique de l'utilisateur mais à un défaut du produit. Jeff Schewe en est un bon exemple (compétentissime mais fanatique).

Les rapports de force entre ces groupes ne sont plus aussi équilibrés qu'ils le furent dans le passé (et pas seulement chez Adobe). Les causes les plus évidentes en sont l'absence de compétiteurs, une politique de profit immédiat, un déficit de vision à long terme et une incompréhension totale du fait que la qualité est la meilleure garantie pour des revenus et des économies à long terme (et je pense ici en particulier aux méthodologies de développement modernes qui permettent un contrôle de qualité pendant le développement et non pas après coup). En ce qui concerne Adobe, leur politique de qualité au début des années 90 était totalement différente. Elle a fait leur réputation. Maintenant ils en vivent et oublient un peu leurs fondamentaux d'il y a 20-25 ans...

[Jc.]

j'ai LR 3.6. LR 4 ça rame vraiment plus en comparaison ? mon outil informatique : Intel Core 2 Quad Q8200, 8 go mémoire.

Tu ne devrais pas sentir de différence "agaçante"...

[Manu_14]

...Les causes les plus évidentes en sont l'absence de compétiteurs, une politique de profit immédiat, un déficit de vision à long terme et une incompréhension totale du fait que la qualité est la meilleure garantie pour des revenus et des économies à long terme...

Si cet état d'esprit était confiné aux éditeurs de logiciels, le monde serait plus gai...

[lawre51]

Pat tu en veux à Adobe.

Crois tu sincèrement qu'il n'y ai pas la même logique chez DXo? Que derrière ce grand laboratoire il n'y a que des idées et pas de contraintes financières.....Oui chez Adobe comme chez les autres il y a ce compromis...Cela ne signifie en rien que le travail soit bâclé.

Maintenant le choix du langage interprété n'est pas des plus judicieux. La micro machine passe son temps à traduire les micros instructions à la volée....Avec la quantité de donnée qui transitent entre les étages du pipeline, des registres et de la mémoire, le programme est plus tributaire de la couche soft que matériel.
Sur ce point je suis d'accord avec toi.

On peux s'interroger aujourd'hui sur le choix du SQLlite. Mais dans le cadre d'une application qui n'utilise pas de base de donnée décentralisée, le SQLite  permet un meilleur accès aux données  totalement indépendant de la plateforme, tout en ne portant pas atteinte à la facilité de déploiement de l'application qui l'utilise.
la latence d'accès aux données est ainsi réduite car la liaison entre LR et son catalogue est direct, sans SGBD lourd et coûteux comme par exemple le système client /serveur.
La plateforme.net propose de belles évolutions,notamment avec les nouveaux espaces de noms, parions que, demain, Lightroom réorientera son moteur de base de donnée.

cyril

[Pat91]

Pat tu en veux à Adobe.

Ah non! THG me joue déjà ce refrain depuis plusieurs années, parfois assorti de la variante "théorie du complot". Dans ce monde du tout ou rien et du blanc ou noir, il faut toujours être pour ou contre. Je ne fonctionne pas comme ça. J'ai toujours dit que Lightroom et Photoshop étaient des logiciels sans vrais concurrents. Je me contente de critiquer certaines pratiques commerciales et certains choix techniques discutables. Je n'en veux pas à Adobe en général mais je regrette que certaines personnes chez Adobe prennent des décisions qui vont à l'encontre d'une politique de la qualité (et ce probablement contre l'avis des développeurs).

Cela ne signifie en rien que le travail soit bâclé.

Quand je dis que le contrôle qualité est bâclé, ce n'est pas en me basant sur ce que je pense de la politique marketing d'Adobe. Ce n'est pas une supposition, c'est un fait démontrable. Quand un bug n'est pas présent dans une version bêta et qu'il apparaît dans la release officielle, c'est la preuve indiscutable que les tests de régression adéquats n'ont pas été faits. Le (gros) bug de la RC2 relatif à la visualisation en mode double écran est un autre exemple du même type. Si le passage d'une RC1 à une RC2 introduit de nouveaux bugs, il y a de toute évidence quelque chose de non maîtrisé dans la méthode de travail. Il y a eu beaucoup d'autres cas similaires avec Lightroom. Quand un bug persiste d'une version majeure à une autre, on peut également être sûr qu'il y a un problème dans le cycle de développement.

On peux s'interroger aujourd'hui sur le choix du SQLlite. Mais dans le cadre d'une application qui n'utilise pas de base de donnée décentralisée, le SQLite  permet un meilleur accès aux données  totalement indépendant de la plateforme, tout en ne portant pas atteinte à la facilité de déploiement de l'application qui l'utilise.
la latence d'accès aux données est ainsi réduite car la liaison entre LR et son catalogue est direct, sans SGBD lourd et coûteux comme par exemple le système client /serveur.
La plateforme.net propose de belles évolutions,notamment avec les nouveaux espaces de noms, parions que, demain, Lightroom réorientera son moteur de base de donnée.

J'ai toujours été dubitatif sur la capacité de SQLite à fonctionner correctement dans un environnement multithreads et Lightroom utilise de toute évidence de nombreux fils d'exécution (et on peut d'ailleurs mettre en évidence de temps en temps des problèmes de synchro). SQLite n'est déjà pas capable de fonctionner en accès multiples, c'est dire (c'est d'ailleurs la raison pour laquelle Adobe interdit l'utilisation d'un disque réseau pour stocker les catalogues). Il y a d'autres solutions locales performantes et probablement mieux adaptées.

Je suis d'accord sur la remarque concernant .Net. C'est portable et cette technologie présente un gros avantage sur LUA : lors de la compilation initiale à la première exécution, le framework .Net produit directement du code machine et pas des byte codes interprétables par une runtime. De plus, .Net permet la mise en oeuvre très facile de méthodologies de test modernes comme le TDD (Test Driven Development). Cette approche permet de détecter la majorité des bugs pendant le développement et non pas chez le client. Mais la majorité des développeurs à qui je l'ai enseignée m'a toujours tenu le même discours : c'est très bien mais ça allonge le cycle de développement. Et quand je leur expliquai qu'à moyen terme cela faisait gagner du temps (moins de recherches stériles en cas de bug indétecté) et de l'argent (beaucoup moins de support client), la réponse était toujours la même : le marketing veut que le produit soit prêt le plus tôt possible. Donc vision à court terme et profit immédiat sont favorisés au détriment du bénéfice à long terme, de la qualité et de la satisfaction client.

PS : dans les temps glorieux où je faisais partie des "Microsoft MVP" et où j'enseignais de temps en temps chez un formateur bien connu, j'ai connu un Cyril qui s'occupait de .Net. Coïncidence?

[lawre51]

Non Pat, je ne suis pas ce Cyril!

Je crois savoir que l'équipe de développement n'est pas une grande équipe...Ceci peut peut-être expliquer cela.
Je suis persuadé que Lightroom a un bel avenir, et je crois qu'il y a de plus en plus d'adeptes......Le code source tel qu'il est aujourd'hui évoluera demain et les axes de travail seront sûrement redéfinis. Un logiciel pour vivre, doit être capable d'accomplir cette mutation....ça, tu le sais. Donc je suis confiant sur l'avenir même si je partage partiellement ton analyse sur les choix de codage.

Mais étant donné que je ne connais pas le code source, je me garderais bien de faire la moindre critique structurelle. Je ne peux juger que le comportement du logiciel et je trouve qu'effectivement travailler à une meilleure performance est nécessaire......DXo a eu ce problème avec la version 6. Ils ont corrigé le tir......Soyons confiants.

[THG]

Lua sert essentiellement pour l'interface de Lightroom.

Les raisons de son adoption ont été largement expliquées par les fondateurs du logiciel.

[Pat91]

Lua sert essentiellement pour l'interface de Lightroom.
Les raisons de son adoption ont été largement expliquées par les fondateurs du logiciel.

Explication n'est pas raison et tout dépend de ce que l'on inclut dans le vocable "interface". Ce qu'ils n'ont encore jamais commenté avec précision, ce sont les raisons profondes des différences de performances entre LR et Camera RAW. Je reste extrêmement curieux sur ce point.

[THG]

Explication n'est pas raison et tout dépend de ce que l'on inclut dans le vocable "interface". Ce qu'ils n'ont encore jamais commenté avec précision, ce sont les raisons profondes des différences de performances entre LR et Camera RAW. Je reste extrêmement curieux sur ce point.

ah bon ?

ce n'est pourtant guère compliqué : ACR n'est pas assis sur une base de données, et la mise ne cache de certaines opérations - là où c'est possible - n'est certainement pas la même.

[Pat91]

ah bon ?
ce n'est pourtant guère compliqué : ACR n'est pas assis sur une base de données, et la mise ne cache de certaines opérations - là où c'est possible - n'est certainement pas la même.

Eh bien justement. C'est là que nous revenons aux messages précédents : si le simple fait de mettre à jour le catalogue et l'historique justifie de tels écarts, c'est qu'il y a un problème massif au niveau du SGBD (SQLite). J'exclus la mise à jour des XMP puisque l'écart est présent même si la mise à jour automatique des XMP est désactivée.

Chaque opération de correction ne nécessite que quelques kilooctets à stocker dans un champ de la base de données. Cela ne prend qu'un temps ridiculement court par rapport aux opérations de calcul qui découlent de cette correction (en particulier quand le nombre de corrections locales augmente car c'est là que les écarts avec Camera RAW sont les plus flagrants). C'est là (entre autres choses) que je soupçonne une erreur de conception ou de codage. Comme par exemple une erreur assez fréquente qui consiste à ouvrir et à fermer la base de données à chaque accès pour des raisons de sécurité au lieu de la garder ouverte en permanence. Erreur très fréquente qui allonge considérablement les temps de réponse.

Cela peut également être un choix délibéré parce que SQLite n'est pas sûr en multithreading. De ce fait, cela ne serait plus une erreur mais une obligation : si plusieurs fils d'exécution dans Lightroom ont besoin d'accéder simultanément à la base de données - ce qui arrive tout le temps - et que les développeurs n'ont pas confiance, ils ont pu décider d'ouvrir et de fermer systématiquement après usage pour sécuriser les accès. Dans ce cas, le temps consacré à la manipulation des données via SQLite devient infiniment plus long (en programmation, le coût en temps de l'ouverture d'une connexion sur une base de données même locale est considérable par rapport au temps nécessaire pour une simple lecture ou une écriture dans un champ une fois la base ouverte). Je serais également curieux de savoir au travers de quelle couche logicielle la connexion sur la base de données est effectuée via le programme principal. Là également, il peut y a avoir des écarts massifs selon la technologie utilisée.

Je pense que l'on pourrait vérifier cela assez facilement avec les outils adéquats (qui n'ont plus droit de cité chez moi ). Encore une fois, je ne peux pas affirmer mais je constate : il y a un écart important et il n'est pas, à mon sens, justifié.

Sur ce point, on pourrait d'ailleurs imaginer une autre approche... Actuellement, les modifications sont écrites et consolidées dans la base de données au fur et à mesure de leur exécution. Est-ce vraiment nécessaire ? Est-ce que cette opération ne pourrait pas être décalée dans le temps et réalisée seulement quand on change d'image ou que l'on quitte le programme ? D'un côté il y a la garantie d'une sauvegarde des corrections en temps réel : en cas de crash, les infos sont en général récupérées telles quelles. Si les crashes sont fréquents, c'est une bonne idée . De l'autre côté, on pénalise les performances.

On pourrait cependant travailler comme avec les disques durs : en écriture les données sont mises en cache en mémoire et envoyées physiquement sur le disque quand on n'a rien d'autre à faire. S'il y a une coupure de courant ou un crash, il y a un risque de perte des données créées récemment. Mais ce n'est pas toi qui va arguer que LR se plante tout le temps, non ? Et on pourrait de toute façon ajouter une commande de sauvegarde (flush des données) que l'on pourrait activer de temps en temps (éventuellement automatiquement à intervalles réguliers) pour préserver le travail en cours.

Juste une idée...

[kaf]

Eh bien justement. C'est là que nous revenons aux messages précédents : si le simple fait de mettre à jour le catalogue et l'historique justifie de tels écarts, c'est qu'il y a un problème massif au niveau du SGBD (SQLite). J'exclus la mise à jour des XMP puisque l'écart est présent même si la mise à jour automatique des XMP est désactivée.

Chaque opération de correction ne nécessite que quelques kilooctets à stocker dans un champ de la base de données. Cela ne prend qu'un temps ridiculement court par rapport aux opérations de calcul qui découlent de cette correction (en particulier quand le nombre de corrections locales augmente car c'est là que les écarts avec Camera RAW sont les plus flagrants). C'est là (entre autres choses) que je soupçonne une erreur de conception ou de codage. Comme par exemple une erreur assez fréquente qui consiste à ouvrir et à fermer la base de données à chaque accès pour des raisons de sécurité au lieu de la garder ouverte en permanence. Erreur très fréquente qui allonge considérablement les temps de réponse.

Cela peut également être un choix délibéré parce que SQLite n'est pas sûr en multithreading. De ce fait, cela ne serait plus une erreur mais une obligation : si plusieurs fils d'exécution dans Lightroom ont besoin d'accéder simultanément à la base de données - ce qui arrive tout le temps - et que les développeurs n'ont pas confiance, ils ont pu décider d'ouvrir et de fermer systématiquement après usage pour sécuriser les accès. Dans ce cas, le temps consacré à la manipulation des données via SQLite devient infiniment plus long (en programmation, le coût en temps de l'ouverture d'une connexion sur une base de données même locale est considérable par rapport au temps nécessaire pour une simple lecture ou une écriture dans un champ une fois la base ouverte). Je serais également curieux de savoir au travers de quelle couche logicielle la connexion sur la base de données est effectuée via le programme principal. Là également, il peut y a avoir des écarts massifs selon la technologie utilisée.

Je pense que l'on pourrait vérifier cela assez facilement avec les outils adéquats (qui n'ont plus droit de cité chez moi ). Encore une fois, je ne peux pas affirmer mais je constate : il y a un écart important et il n'est pas, à mon sens, justifié.

Sur ce point, on pourrait d'ailleurs imaginer une autre approche... Actuellement, les modifications sont écrites et consolidées dans la base de données au fur et à mesure de leur exécution. Est-ce vraiment nécessaire ? Est-ce que cette opération ne pourrait pas être décalée dans le temps et réalisée seulement quand on change d'image ou que l'on quitte le programme ? D'un côté il y a la garantie d'une sauvegarde des corrections en temps réel : en cas de crash, les infos sont en général récupérées telles quelles. Si les crashes sont fréquents, c'est une bonne idée . De l'autre côté, on pénalise les performances.

On pourrait cependant travailler comme avec les disques durs : en écriture les données sont mises en cache en mémoire et envoyées physiquement sur le disque quand on n'a rien d'autre à faire. S'il y a une coupure de courant ou un crash, il y a un risque de perte des données créées récemment. Mais ce n'est pas toi qui va arguer que LR se plante tout le temps, non ? Et on pourrait de toute façon ajouter une commande de sauvegarde (flush des données) que l'on pourrait activer de temps en temps (éventuellement automatiquement à intervalles réguliers) pour préserver le travail en cours.

Juste une idée...

Sauf que ce genre d'idée sort largement du domaine de compétence du public ciblé par LR. Le photographe lambda n'a aucune idée de ce qu'est un sgbdr, encore moins de ce que représente une connexion ou une transaction. Lui demander de les gérer lui-même (parce que c'est en gros ce que tu proposes) ne pourrait mener qu'à la confusion ou pire, à la perte d'information. Je ne connais pas le fonctionnement en interne de LR, et il y a certainement des choses améliorables côté performances, mais je ne crois pas que les choses soient aussi simples que tu sembles le penser. Ne serait-ce que parce que l'utilisateur du logicien n'est pas informaticien mais photographe!

[Pat91]

Lui demander de les gérer lui-même (parce que c'est en gros ce que tu proposes) ne pourrait mener qu'à la confusion ou pire, à la perte d'information.

Ne tombons pas dans la caricature et n'exagérons rien . J'ai bien dit que la sauvegarde décalée peut être automatisée. C'est d'ailleurs exactement ce qui se passe, encore une fois, avec les disques durs. On ne demande pas à l'utilisateur de gérer lui-même le flush des écritures décalées. Cela est réalisé automatiquement de manière régulière quand l'utilisateur est inactif ou que l'on ferme la session ou que l'on arrête (proprement) le système. On ne demande pas à l'utilisateur de devenir informaticien pour ça. Rien de ce que je propose ci-dessus n'implique nécessairement une contrainte supplémentaire pour l'utilisateur.

[kaf]

Rien de ce que je propose ci-dessus n'implique nécessairement une contrainte supplémentaire pour l'utilisateur.

Ben si tu ajoutes un bouton pour vider le cache manuellement, immanquablement, les gens vont se demander pourquoi et ne comprendront rien

Par contre, je pense que certaines choses pourraient être améliorées aussi, mais trouver le juste équilibre entre performances et sécurité est difficile!

[Pat91]

Ben si tu ajoutes un bouton pour vider le cache manuellement, immanquablement, les gens vont se demander pourquoi et ne comprendront rien

Disons que je retire cette proposition malvenue, typique d'un développeur , et que l'on reste sur le principe d'un automatisme. Mais ça ne change rien à ma proposition : décaler complètement la mise à jour de la base de données dans le temps au lieu de mettre à jour en temps réel. À partir du moment où la migration vers le 64-bit commence à se généraliser, occuper quelques kiloctets de plus en mémoire pour cacher ces infos ne portera pas à conséquence. Au point où nous en sommes...

Cette idée ne fait d'ailleurs que prolonger la recommandation qui est déjà faite de ne pas activer la sauvegarde automatique des XMP, justement à cause de l'impact sur les performances. Ce mécanisme (la mise à jour d'un fichier XML) pose en fait exactement la même problématique. C'est un processus lent par nature.

En fait, je suppose qu'il y a déjà une sorte de temporisation dans LR mais elle est très courte si j'en juge par les données que je récupère quand Lightroom se crashe sur mon système. En général, je retrouve les choses en l'état quand je relance. Si la fréquence des crashes diminue, je peux admettre de perdre quelques données de temps en temps à cause d'une mise à jour décalée dans le temps si je récupère en contrepartie de la performance.

[lawre51]

Sur ce point, on pourrait d'ailleurs imaginer une autre approche... Actuellement, les modifications sont écrites et consolidées dans la base de données au fur et à mesure de leur exécution. Est-ce vraiment nécessaire ? Est-ce que cette opération ne pourrait pas être décalée dans le temps et réalisée seulement quand on change d'image ou que l'on quitte le programme ? D'un côté il y a la garantie d'une sauvegarde des corrections en temps réel : en cas de crash, les infos sont en général récupérées telles quelles. Si les crashes sont fréquents, c'est une bonne idée . De l'autre côté, on pénalise les performances.
Juste une idée...

J'ai une  approche qui suit la tendance actuelle.....Travailler en mode déconnecter. Le framework 4.0 fournit le DataSet, PiecesTableAdapter, l'objet Command et connexion etc etc.....
L'idée est de charger les données, réaliser un container xml afin de stocker tout ça, puis demander une nouvelle connexion afin de mettre à jour vers la BDD. En assurant une gestion multi-accès sécurisée. On minimise les accès à la BDD, on garantit un niveau de sécurité etc etc

Donc c'est exactement celle que tu évoques Pat en libérant le processus d'une écriture lecture à la BDD permanente.
Je suis juste un petit amateur, et je peux me planter.

[Pat91]

J'ai une  approche qui suit la tendance actuelle.....Travailler en mode déconnecter. Le framework 4.0 fournit le DataSet, PiecesTableAdapter, l'objet Command et connexion etc etc.....
...
Je suis juste un petit amateur, et je peux me planter.

Pas du tout. C'est une des approches que j'ai enseignées aux développeurs qui fréquentaient mes cours .Net. Le Dataset de .Net est en fait une mini base de données en mémoire que l'on peut strictement limiter aux données dont on a besoin. C'est une approche tout à fait en phase avec ce que je propose. Mais elle suppose qu'Adobe adopte le framework .Net .

Il y a à l'encontre de cette technologie des a priori bien regrettables. D'abord, certains la rejettent d'emblée puisqu'elle vient de Microsoft. Ensuite, beaucoup pensent qu'elle n'est pas portable sur les plates-formes non Windows (et découvrent avec surprise qu'elle est disponible pour Mac et Linux et d'autres plates-formes et que c'est une technologie ouverte - toutes les spécifications sont disponibles -). Le framework .Net est pourtant ce que j'ai vu de plus intelligent et de plus abouti comme technologie de développement depuis que j'ai commencé à coder, ce qui remonte à la fin des années 70. DxO l'a d'ailleurs adoptée mais seulement partiellement, ce qui compromet un certain nombre des avantages qui lui sont liés. Enfin, la mise en oeuvre de méthodologies de test modernes et performantes est particulièrement aisée sur ce framework. Tout cela relègue LUA et consorts aux poubelles de l'histoire informatique. Mais que faire contre les préjugés ?

[kaf]

Pas du tout. C'est une des approches que j'ai enseignées aux développeurs qui fréquentaient mes cours .Net. Le Dataset de .Net est en fait une mini base de données en mémoire que l'on peut strictement limiter aux données dont on a besoin. C'est une approche tout à fait en phase avec ce que je propose. Mais elle suppose qu'Adobe adopte le framework .Net .

Il y a à l'encontre de cette technologie des a priori bien regrettables. D'abord, certains la rejettent d'emblée puisqu'elle vient de Microsoft. Ensuite, beaucoup pensent qu'elle n'est pas portable sur les plates-formes non Windows (et découvrent avec surprise qu'elle est disponible pour Mac et Linux et d'autres plates-formes et que c'est une technologie ouverte - toutes les spécifications sont disponibles -). Le framework .Net est pourtant ce que j'ai vu de plus intelligent et de plus abouti comme technologie de développement depuis que j'ai commencé à coder, ce qui remonte à la fin des années 70. DxO l'a d'ailleurs adoptée mais seulement partiellement, ce qui compromet un certain nombre des avantages qui lui sont liés. Enfin, la mise en oeuvre de méthodologies de test modernes et performantes est particulièrement aisée sur ce framework. Tout cela relègue LUA et consorts aux poubelles de l'histoire informatique. Mais que faire contre les préjugés ?

+1

[lawre51]

Patrick,

Pourquoi écris tu "Pas du tout " puisque c'est une approche tout à  fait en phase avec ce que tu proposes.

Oui, le jeu de résultat de la requête d'un objet DataSet ADO.NET peut être recrée à partir d'un flux ou d'un document XML pourvu qu'il ai été mappé vers ce document standard.

[Pat91]

Pourquoi écris tu "Pas du tout " puisque c'est une approche tout à  fait en phase avec ce que tu proposes.

C'est simplement la réponse à l'affirmation : "Je suis juste un petit amateur, et je peux me planter.".

[geraldb]

J'ai installer la version 4.1 RCII sur la 4.0, pas de problèmes
remarqués à ce jour, catalogue en place, 2ème écran sans
problème.
Il me semblerait que c'est plus rapide, est-ce subjectif!
Par contre, pas de boite de dialogue à l'ouverture, jusqu'à
quelle date est-elle valable...