Claude SIMON a écrit 549 commentaires

C'est tout à fait cela ; tous les logiciels développés à l'aide de cette boîte à outils ont été financés pas mes clients, et je n'en dispose donc pas librement, d'où l'impossibilité des les publier. De ce fait, j'ai commencé, à titre personnel, le développement du logiciel présenté ici. Comme je l'ai indiqué dans le titre, ce n'est que le commencement. Les toutes prochaines versions porteront sur la consolidation des mécanismes de base (version Web, développement de plugins relatifs à de nouveaux types de champs…), ainsi que sur l'amélioration du packaging, afin de faciliter le déploiement du logiciel par toute personne qui s'y intéresse. Puis seront, petit à petit, développées les fonctionnalités qui permettront à ce logiciel de remplir les objectifs que je lui ai fixé, objectifs qui pourront évoluer en fonction des suggestions de ceux qui l'auront testé (ce qui devrait prochainement être facilité par la mise en ligne d'une version de démonstration).

Zelbinium, la programmation ludique

Je suis en train de développer un Logiciel Libre, que je présente ici à titre de démonstration de certaines technos, en attendant que le logiciel soit suffisamment avancé pour présenter un intérêt en lui-même. Ces technos sont incluses dans un framework, et je compte les réutiliser à travers ce framework (je les utilise d'ailleurs déjà) pour développer d'autres logiciels, ceux de mes clients, mais également des logiciels pour mon propre usage, auquel cas je placerais ces derniers sous licence libre, et ils feront probablement l'objet d'une publication sur ce site, à l'instar de ceux que j'ai déjà publiés.
En publiant ce journal, je n'attends rien en retour, mais s'il y a des retours, je les étudierais attentivement, comme je l'ai fait pour les commentaires publiés jusqu'à présent, et cela quelque soit la nature de ces retours.
Quant à la qualité auquel je fais référence, c'est celle, comme je l'ai déjà écrit, perçue par les utilisateurs de mes logiciels et dont ils me font part au travers de leurs retours. Même si certains autres critères qualitatifs sont importants, ils demeurent néanmoins secondaires face à ceux qui conditionnent la satisfaction des utilisateurs.
Quand aux principes que tu listes, ça correspond, grosso-modo, à ma pratique professionnelle. D'ailleurs, je ne vois pas ce qui, dans ce journal ou ailleurs, suggère que cela puisse ne pas être le cas. Et, plus précisément, j'ai déjà développé pour mes clients et livré des applications qui mettent en œuvre ces technos, et les retours que j'en ai sont excellents. Mais comme je ne peux pas publier ces applications, et que j'ai, en outre, envie de pousser ces technos dans leurs retranchements, j'ai commencé à développer l'application qui fait l'objet de ce journal.
Avec ce journal, et certains autres que j'ai publiés, j'ai remarqué une certaine hostilité envers mes technos, probablement parce qu'elles vont à l'encontre de certains dogmes. Mais, ni dans ce journal, ni dans aucun autre, malgré les tentatives répétées de certains, personne n'a réussi à mettre en défaut mes technos d'une quelconque manière. Tant que cela demeurera le cas, je continuerais à développer et à présenter des logiciels basées sur ces technos, et tant pis pour ceux qui les rejettent. Ce qui ne signifie pas que je ne suis pas ouvert à la critique, car je n'ai pas la prétention d'avoir crée quoique ce soit de parfait…

Zelbinium, la programmation ludique

Cependant, ma techno permet à tout un chacun de modifier l'interface :
- à l'aide d'un simple éditeur de texte, sans avoir mettre en œuvre d'autres outils (compilateur ou autres…),
- essentiellement juste en connaissant HTML et XSLT/XML ; à défaut, il pourra s’adresser à n'importe quel développeur Web digne de ce nom.

Tu optimise pour le mauvais problème.

Le développeur web, il va préférer faire du web. Il a ses outils, sa communauté, ses navigateurs.

Le développeur natif, il va faire du natif.

Et il y a un troisième type de développeur, dont je suis peut-être l'unique représentant aujourd'hui (j'espère que non), qui veut développer du Web, et du natif, tout en maintenant un seul et unique code commun aux deux (ce qui va faire l'objet d'un prochain journal, comme signalé dans celui-ci).

Le boite qui veut modifier un soft, elle a des développeurs en interne pour faire ca, ou elle sous traite.
Le fait que ca soit modifiable avec un simple éditeur de texte ne change rien au fait que le tooling est très important. Debugger/view inspector/logger etc. Tu enlève le compilo de la chaîne, cool, mais on a toujours besoin de ces autres outils. Au final, tu te retrouves avec le même problème sur le bras (cf mon point sur les compromis, le tien est tres mauvais ici).

Outils qui sont familiers à n'importe quel développeur Web. Donc, si l'utilisateur ne veut pas se coltiner ces outils pour la modification de l'interface, il trouvera facilement quelqu'un pour le faire à sa place. En tout cas, plus facilement qu'avec une application native classique sur MacOS, iOS, Windows…

Quel est l'intérêt de déployer une appli native basée sur des technos web, quand on a un browsers installé sur toutes les machines, ce qui élimine entièrement le problème du deployment/packaging etc? (À nouveau les compromis, tu te retrouves avec le pire des 2 mondes si tu part sur une techno hybride).

De pouvoir déployer la même application indifféremment dans sa version Web et/ou sa version native, sans rien modifier à son code. Bon, après, reste le vieux débat Web vs natif, mais qui, dans le cadre de mon appli. est sans intérêt, puisqu'on la déploie dans la forme que l'on veut.

Dit autrement, tu résouds un problème qui n'existe pas.
Les customisations qui ne sont que purement cosmétique sont par définitions triviales, et donc à très faible valeur ajoutée. Optimiser pour ce cas est une perte de temps.
Les customisations non triviales vont requérir des ingénieurs (vs bien falloir écrire du code pour gérer telle ou telle fonctionnalité différemment), qui maîtrisent donc la technologie et qui n'auront aucun problème à compiler une appli.

L'interface de mon appli. est en HTML5. J'offre à l'utilisateur la possibilité de modifier ce code HTML5 à volonté sans avoir à solliciter le développeur de l'application, et, au pire, mais ce n'est pas indispensable, en sollicitant le développeur Web de son choix. C'est tout. Maintenant, il en fait usage ou non, c'est son problème ; simplement, la possibilité existe.

A priori, mais je n'ai pas encore approfondi le sujet, cela devrait permettre de modifier une application pour, par exemple, l'adapter à l'usage des mal/non-voyants

L'accessibilité va plus loin qu'un simple problème de contraste.

Jette un œil à ce qu'ios/OS X font dans ce domaine si tu me crois pas. Ca demande systématiquement beaucoup de taff, dans la conception même de l'appli, et dans son implémentation. Même sous iOS qui premache 90% du boulot pour toi, tu te retrouves à devoir écrire du code custom à droite à gauche. C'est pas quelque chose que tu greffes après coup en changeant un peu les vues.

Soit dit en passant, ca te fait pas un peu peur de ne pas avoir approfondi le sujet? Disons que c'est un point central de ta technos, comment peut tu prétendre avoir fait les bon choix si tu n'as pas d'idée précise des cas d'utilisation?

Non, ce n'est pas un point central, c'est juste un des avantages. Et ce que je n'ai pas approfondi, ce sont les possibilités de HTML dans ce domaine. Si elles ne sont pas encore suffisantes, il y a de fortes chances que cela se développe par la suite. Le cas échéant, ça sera à la portée de n'importe quel développeur Web d'adapter l'appli. Mais, encore une fois, cela dépend de HTML, pas de ma techno.

A l'origine, je générais directement le .h, mais, en passant par le XML, cela ouvrait la possibilité de générer l'API dans un autre langage, en utilisant un autre fichier XSL.

Ce que je dit, c'est que l'api en question, c'est du code. Écrit la en code directement, plutôt que de la decrire en xml pour ensuite générer du code. T'as rien à gagner à l'écrire en xml, c'est infiniment plus verbeux et casse gueule.
La philosophie sous jacente à ce genre de technos, c'est que ca permettait de générer des stubs client et serveur automatiquement. Sauf que depuis, on s'est rendu compte que c'est vachement plus simple et pratique de juste écrire le code. Les stubs ne servent à quasiment rien, et dans les rares cas ou ils servent, t'as plus vite fait de les générer à partir de l'interface écrite en code. Cf par exemple ce que fait Jersey qui te génère ton wadl à partir de l'appli.

L'API en question contient du code, mais pas le code du backend. En gros, elle expose les objets gérés par le backend sous forme d'objets C++, et elle sérialise simplement les valeurs des différents paramètres des différentes méthodes de ces objets pour qu'ils puissent transiter via le canal de communication avec le backend. Et ça, c'est du code chi emm pénible à écrire, donc je préfère que l'ordinateur le fasse à ma place (c'est l'un des buts de l'informatique, non ?). Il n'y a pas l'ombre du soupçon de code du backend dans cet API, ni d'ailleurs dans le XML qui est utilisé pour la générer. J'ai mis un lien dans le journal sur un fichier contenant une telle API, ainsi que sur le fichier XML correspondant ; tu pourras t'en persuader toi-même.

Bon, j'ai encore regardé sur le Web de quoi il s'agissait, et je ne vois vraiment pas en quoi cela s'applique à ce projet. Pourrais-tu fournir une définition de ce concept, pour être sûr que l'on parle de la même chose, et m'indiquer un exemple de ce qui, dans mes technos, te paraît y correspondre ?

Tu passes beaucoup de temps à construire une plateforme qui émule de façon très pauvre la plateforme sur laquelle elle tourne.
Le concept de backend par exemple: pourquoi introduire un tel système? Ceux qui veulent parler à un backend réseau le feront plus vite et efficacement avec une api rest, tout en ayant une plus grande latitude de choix technologiques.
Le html5: les développeurs auront plus vite faite de coder pour un navigateur plutôt que d'utiliser ta version. Au final, tu construit une plateforme qui émule la plateforme sur laquelle elle tourne, et n'apporte pas grand chose, à part des contraintes.

Ma plateforme n'émule rien du tout. Une appli. native basée sur cette plateforme est, du point de vue de l'interface, une appli. Web, mais débarrassée de tous ce qui est relatif au réseau. Son interface est rendu par Chromium, mais dans une version débarrassée de toute l'interface nécessaire à la navigation Web. Et, coté traitement, on a tous les avantages du natif, c'est-à-dire qu'il n'est nullement besoin de passer par une couche REST ; on a accès directement au backend. Et cette plateforme permet de déployer la même appli en tant que qu’application Web, sans rien changer au code, et donc toujours sans avoir à recourir à une surcouche REST.

Zelbinium, la programmation ludique

Ok, donc visiblement, on parle de simple définition d'ui en déclaratif? Tu fais pas de bindings (e.g. Définir dans le xml que ce champ reçoit le contenu de la variable foo du contrôleur)?

Ben, au final, le code derrière l'UI, c'est simplement du bête HTML5, similaire à ce qu'on trouve dans la plupart des pages Web ; il est simplement mis en forme à l'aide de XSLT… CEF, c'est, grosso-modo, le navigateur Chromium, mais sans les éléments d'interface qui en font un navigateur Web, c'est-à-dire juste le moteur de rendu. Tout aussi grosso-modo, CEF est à Chromium ce que XULRunner est à Firefox (bon, je ne sais si ça va parler à beaucoup de monde, ça). Mon appli donne à CEF (donc Chromium) du XML et du XSL, et CEF se charge de transformer ça en HTML, dont il assure également le rendu.

Effectivement, la plupart des technos ont une forme de compilation, ça évite de se taper le surcoût de parser du xml à la volée pour qq chose qui n'est pas censé être changé après le packaging de l'appli. L'exception, de mémoire, c'est le truc de Facebook, components il me semble, et eux ont un besoin bien précis (j'y reviendrais).

Si rares sont ceux qui le font c'est parce que le besoin est faible. Changer un storyboard et relancer l'appli sous iOS, c'est moins d'une seconde. Tu changes juste une ressource qui est rapide à compiler, tu touches pas le code, ça va vite.
Pour ceux qui veulent modifier l'ui d'un logiciel libre, c'est d'une part assez rare, et d'autre part généralement un peu plus compliqué que juste changer le layout. Optimiser pour la simplicité de compilation n'est pas un bon calcul.

Je ne comprend pas trop ta dernière phrase. Cependant, ma techno permet à tout un chacun de modifier l'interface :
- à l'aide d'un simple éditeur de texte, sans avoir mettre en œuvre d'autres outils (compilateur ou autres…),
- essentiellement juste en connaissant HTML et XSLT/XML ; à défaut, il pourra s’adresser à n'importe quel développeur Web digne de ce nom.

A priori, mais je n'ai pas encore approfondi le sujet, cela devrait permettre de modifier une application pour, par exemple, l'adapter à l'usage des mal/non-voyants, sans pour cela avoir à impliquer le développeur de l'application. Je pense que pour faire la même chose avec les autres technos citées dans ce journal, il faudrait l'intervention d'un développeur. Accessoirement, cela permet facilement au développeur de déléguer la réalisation du design de l'interface, vu qu'il ne manque pas de personnes ayant les compétences nécessaires (développeurs Web). Personnellement, n'ayant aucune affinité particulière avec HTML et consorts (CSS, JS…), c'est quelque chose qui m'arrange bien.

Bon, quand je parle de l'utilisateur, il peut aussi s'agir d'une entreprise qui adapte l’interface du logiciel à sa charte graphique, par exemple…

Ce qu'il se passe pour Facebook est qu'ils ont une appli gigantesque, dont le contenu change en permanence et en temps réel, maintenue par des dizaines de personnes et releasee tous les 15 jours. la modifier sans tout peter est très dur. Le feed se met à jour constamment et affiche les likes/commentaires etc en temps reel.

Le modèle traditionnel "modifie la vue pour afficher les données" marche mal, parce qu'il ya trop d'état différents pour chaque vue, et donc calculer le diff est dur.
Leur solution à ce problème, c'est de partir sur un modèle 100% événementiel/stateless. C'est plus simple de tout balancer et de rerendre les vues quand les notifications de changement de données arrivent. Charge à la team du framework de recycler les vue pour que ca rende toujours à 60fps sans bouffer toute la ram du device.
Le fait que les vues se recharges automatiquement à chaud est juste un effet de bord sympa, c'est tout, c'est pas un but en soi.

En effet. J'ai cité cela pour juste souligner la facilité avec laquelle on peut modifier l'interface.

Bref, assez parlé de Facebook, retournons à xdh chose.
- quel problème xdh-chose essaye de résoudre?
- en quoi ce problème est pertinent?
- en quoi la solution de xdh améliore l'état actuel?

Je pense que tu parle des attributs data-xdh-.... Ça n'est pas censé résoudre un problème en particulier, c'est juste mon approche pour gérer :
- pour les data-xdh-onevent(s), la mise en place des gestionnaire d’événements,
- pour les xdh-data-cast(s), l'accessibilité (je ne trouve pas de terme adéquat pour désigner le fait qu'un élément soit hidden/disabled…).

Il y a également les data-xdh-widget, mais qui ne sont pas (encore) utilisés dans cette appli, et qui sont dédiés à la gestion des widgets basés sur jquery, qui semblent assez répandus.

Tout ça permet de confier au logiciel la mise en place du code JS généralement mis en œuvre pour ces usages.

Un des concepts de base en ingénierie est qu'on ne résoud jamais vraiment un problème. On transforme un problème en un autre, mais cet autre problème vient avec ses inconvénients. Si les nouveaux inconvénients sont moins nombreux/courants/ennuyeux que ceux qu'on avait a la base, on a gagné. En d'autres termes, on fait des compromis.
Un compilateur rend plus simple l'écriture de code, par exemple, mais le langage vient avec ses tares, et cache le fonctionnement sous jacent de la machine. En pratique, c'est un gain net.

Étant le développeur de cette appli, je m'abstiendrais de me prononcer sur ce point ; on pourrait m'accuser de manquer d'objectivité :-).

J'ai du mal, personnellement, à voir le gain sur le compromis que tu fais ici. Tu gagnes sur le code, mais tu te retrouves avec plus de 1000 lignes de xml aride pour une appli triviale. ça coûte cher le setup de l'appli, même les monstres à là spring font tout ce qu'ils peuvent pour réduire ca le plus possible (et eux font beaucoup plus que toi avec ce setup).

Là je pense que tu parle des fichiers de configuration (les .xcfg). Le problème vient du packaging. En réalité, mes fichiers de configurations sont plus simples que ceux qui sont fournis dans les packages (comme on peut le voir en regardant les version hébergées dans le repository mercurial dont l'adresse est donné dans le journal), car ils s'appuient sur un préprocesseur XML, ce qui permet d'utiliser des macros, et de répartir le contenu sur plusieurs fichiers. La version packagée est celle après application du préprocesseur XML ; c'est comme si on livrait les sources d'un programme C/C++ après les avoir passés par le préprocesseur C. C'est certainement quelque chose qui devrait être amélioré, mais ce n'est pas évident à réaliser. Ceci dit, ça reste du XML, mais il ne sert qu'à remplir une registry interne. On peut parfaitement envisager de remplir cette registry à l'aide d'un autre format, comme JSON par exemple…

Le xml est particulièrement aride à lire, très long, tres verbeux et ca se répète énormément. Ça fait 15-20 ans qu'on sait que les UI déclaratives, c'est cool, mais il faut un éditeur riche pour que ça marche. Ça va plus vite à écrire, et ça permet d'avoir une vue de l'ensemble.
Le xml pour générer les stubs back/front end, on sait depuis soap que c'est une très mauvaise idée. C'est vilain, verbeux et ca résoud quasiment aucun problème, ca en rajoute juste.
Dans l'autre sens, ça marche mieux (par exemple ce que fait jaxrs avec les wadl). La tendance "xml pour générer des stubs" avait le vent en poupe ya 15 ans, tout le monde en revenu parce que c'est un enfer à maintenir et ca ne résoud pas vraiment de problème. C'est plus simple/lisible/naturel d'écrire une interface en code directement.

Pour le XML relatif à l'interface, et celui des fichiers de configuration, j'espère que mes réponses ci-dessus sont assez claires (sinon, ne pas hésiter de me demander des précisions). Pour celui concernant l'API des backend, il s'agit juste d'un fichier intermédiaire, qui n'est pas utilisé lors de l'exécution de l'application. A l'origine, je générais directement le .h, mais, en passant par le XML, cela ouvrait la possibilité de générer l'API dans un autre langage, en utilisant un autre fichier XSL.

Bref, désolé de tailler un costard, mais j'ai beaucoup de ma à voir un intérêt au framework, et à mon avis, ce genre d'approche diminue la qualité plus qu'autre chose.

Inutile d'être désolé. Pour l'instant, tout ce que j'ai lu concernant les autres technos me renforce dans mon opinion que les miennes sont parfaitement viables et légitimes, en théorie du moins. Et c'est justement l'un des buts de l'appli présentée dans ce journal de les mettre à l'épreuve de la pratique.

Aussi, pour ne pas perdre trop de temps avec ça, j'ai établis quelques règles de nommage ; malheureusement, ces règles donnent des noms parfois un peu abscons, mais c’est le prix à payer si l'on veut des noms pas trop longs.

Et bien changes les règles. Rajoutes des voyelles, ça coûte pas plus cher et ça fait des mots lisibles et prononçables.

Là encore, c'est un problème de packaging. Si l'application était correctement packagé, l'utilisateur ne serait jamais exposé à ces noms ; il aurait juste à cliquer sur l'une ou l'autre icône, auxquelles on pourrait donner un nom plus expressif. Mais, vu l'état de l'application, il me semble plus important de me concentrer sur le fond que sur la forme…

Le commentaire sur l'inner platform effect se rapportait au framework, pas aux noms :)

Bon, j'ai encore regardé sur le Web de quoi il s'agissait, et je ne vois vraiment pas en quoi cela s'applique à ce projet. Pourrais-tu fournir une définition de ce concept, pour être sûr que l'on parle de la même chose, et m'indiquer un exemple de ce qui, dans mes technos, te paraît y correspondre ?

Zelbinium, la programmation ludique

Je suis sûr que si, par exemple tu sais que tu fais des templates quand tu en fait (quand tu utilise <>).

Étant donné que c'est quand même du C++, je pense que la présence de templates n'a rien de surprenant…

Globalement pour me donner envie de lire les 50k SLOC (Source Lines Of Code) de code que constitue ton xdhdq, il faut quelque chose qui parle un peu plus aux gens. Moi perso je ne développe pas en C++ depuis pas mal de temps, j'ai pas un grand plaisir à bouffer autant de code.

De l'autre coté c'est dommage de ne pas s'intéresser à l'existant parce que ça constitue une source d'inspiration importante.

En fait, les prémices de mon framework datent d'une vingtaine d'année. A l'époque, je voulais utiliser la STL, mais il était fortement déconseillé dans la documentation de l'utiliser en production. Du coup, j'ai développé mes propres bibliothèques. Après, j'ai regardé l'existant, mais sans aller jusqu'à regarder les détails de l'implémentation, vu que, globalement, cet existant ne m'apportait rien de plus que ce que je n'avais déjà avec mon framework…

Personnellement je n'appellerais pas xdhdq un hello world. C'est plus une vitrine. Le hello world, c'est le code minimal qui permet d'utiliser le cas nominal de ton framework. Par exemple c'est ce qui permet d'avoir une fenêtre avec un bouton dessus et quand tu clique dessus le bouton change de couleur (ou le texte change). Je présume que ça tiens en 3 fichiers C++ et 2 fichiers XML/XSL.

Là, j'avoue, j'ai fauté. Le fait est que, lorsque je démarre le développement d'une nouvelle application, je lance un script qui me met en place une application avec quelques fonctionnalités de base. Ainsi, la première page de l'application permet, soit de créer un nouveau projet, soit de sélectionner l'un de ceux prédéfinis dans le fichier de configuration, soit d'ouvrir un fichier contenant un projet. La seconde page, dont le contenu est conditionné par le choix fait à la première page, permet, soit de continuer sans backend, soit d'en sélectionner un parmi ceux prédéfinis dans le fichier de configuration (ou du projet), soit de charger directement la bibliothèque dynamique correspondant au backend, soit encore de saisir l’adresse et le port du backend auquel l'application doit se connecter. L'essentiel du code de cette application correspond en fait à la gestion des ces fonctionnalités. Les fichiers C++ et XSL correspondant aux fonctionnalités au cœur de l'application sont ceux commençant par Fields (un .h, un .cpp, et deux .xsl).

Zelbinium, la programmation ludique

Si tu veux parler d'une séparation frontend/backend, ou client/serveur, ça existe quand même depuis très très longtemps sous une diversité de formes impressionnate. D'une manière générale, je pense que peu de gens contestent l'utilité de séparer les algorithmes du logiciel et l'interface utilisateur.

La séparation frontend/backend, je l'avais implémenté à l'époque parce que ça me semblait une bonne idée. Vu tous les avantages que cela apporte, je me doute bien que je ne sois pas le seul à mettre en œuvre ce mécanisme, sans toutefois chercher à en savoir davantage à ce sujet. Je l'ai simplement mentionné à titre informatif, sans vouloir impliquer que cela soit une exclusivité de mon framework.

Après, qu'il faille recompiler la partie UI ou modifier le code pour modifier l'interface, ça dépend un peu du type de logiciel, mais ça ne me semble pas forcément primordial. J'ai du mal à voir ce que ça change en termes de maintenabilité du code, par exemple. Si tu as un code super-complexe qui te génème une interface graphqiue à partir de fichiers XML super complexes, tu vas avoir des bugs de partout, et il est très improbable de motiver les gens à apprendre le "framework". Typiquement, pour un logiciel libre, ça veut dire que tu te coupes de la possibilité de recevoir des patches ; un utilisateur ne va pas passer plusieurs mois à se former sur ton framework pour corriger un bug.

Le code pour générer l'interface n'est pas complexe en soi ; ce qui peut être complexe, c'est le code HTML/CSS, et éventuellement JS (sachant que l'on peut mettre du XHTML/CSS/JS directement dans le fichier XSL), mais cela dépend uniquement de ce que veut l'utilisateur. Les fichiers XSL fournis avec l'application ne contiennent que des instructions XSL relativement basiques. Quand au XML, il n'est pas complexe non plus, car il ne contient que les données, et quelques informations associées, destinées à être affichées.

L'isolement technologie a un coût, spécialement pour du logiciel libre. Si tu utilises un binding gtk pour perl, tu as de grandes chances que beaucoup de bricoleurs puissent en un coup d'œil comprendre ce que tu fais. Par ailleurs, être capable de faire tourner ton soft sans passer 3 jours à installer l'environnement de travail peut aussi aider. Au contraire, si le saut technologique est important, cette première étape est rédibitoire. Par exemple, j'ai été faire un tour sur ton github, juste pour cliquer sur quelques fichiers C++ au hasard. Clairement, ton code C++ n'est pas du C++, c'est une sorte de dialecte du C++ qui repose sur des appels de macro dans tous les sens. C'est peut-être justifié, mais ma réaction, c'est "qu'est-ce que c'est que ce bordel, c'est même pas du C++ ce truc". Entre ça et le code généré, j'ai l'impression que comprendre la logique de ton framework nécessite plusieurs semaines de travail. Si en plus tu n'arrives pas à expliquer l'intérêt d'utiliser ce type de technologie, tu vas galérer pour trouver une base d'utilisateurs à mon avis.

Je n'essaye pas de mettre l'accent sur mon framework, d'autant plus qu'il n'est pas documenté (pas dans le sens 'documentation pas rendue publique', mais dans le sens 'documentation réellement inexistante'). Il se trouve que j'ai développé, et que je compte encore développer, quelques logiciels que j'ai placé sous licence libre, et qui me semblent donc parfaitement qualifiés pour faire l'objet de quelques journaux sur ce site. Maintenant, que les gens ne s'y intéresse pas, ou ne s’intéresse qu'au logiciel, ou bien s'intéresse au framework sur lequel ces logiciels s'appuient, c'est leur affaire, tout en étant bien conscient que mes lacunes en matière de communication ne facilite pas les choses, sachant néanmoins qu'il y a plus de chance que les gens s'y intéresse en communiquant mal sur le sujet, qu'en ne communiquant pas du tout. Si, malgré cela, des personnes sont intéressées par ce que je fais, je leur apporterais volontiers tout éclaircissement qui leur paraîtrait nécessaire.

Pour ce qui est de l'installation du logiciel, je suis parfaitement d'accord qu'elle est, dans sa forme actuelle, quelque peu rédhibitoire. Mais ce n'est pas dû à mes logiciels proprement dit, mais à CEF, sur lequel mes logiciels s'appuient dans leur version native. Pour Windows, j'ai essayé de simplifier l'installation en fournissant un package auto-suffisant. Pour les autre environnements, je voudrais pouvoir faire la même chose, mais je ne sais pas faire (ce qui ne veut pas dire que ce n'est pas possible). Tous les autres logiciels que j'ai publié et qui ne dépendent pas de CEF sont installés après décompression de l'archive en lançant simplement un make à la racine de l’archive. Je suis en train d'essayer de mettre en place la même procédure pour ce logiciel-ci, mais ça nécessite de se plonger dans les arcanes de CEF, ce qui prend du temps…

Répondre de manière semi-agressive aux commentaires ne risque pas forcément d'aider non plus, d'ailleurs. Tu t'attendais peut-être à ce que les gens te répondent "c'est génial ton truc, comment personne n'y a jamais pensé avant", mais visiblement, s'ils te disent qu'ils n'ont pas compris et que ça ne leur paraissait pas spécialement nouveau ni même intéressant, ça n'est pas dans le but de te blesser. Si tu es dans l'état d'esprit de répondre "vous êtes tous des cons qui n'y connaissez rien", ça ne va pas être très constructif. Il ne faut pas non plus que ça bride ton entousiasme, si tu penses que ton truc vaut le coup, fonce. Mais n'oublie pas "eat your own dog food": Si ta techno permet de développer sans effort des logiciels super facilement, alors le mieux est de fournir ces logiciels toi-même, jusqu'à ce que les gens se demandent "mais comment ce type peut-il maintenir autant de softs de qualité?", ce qui les amènera sur le côté technique. L'approche inverse me semble au contraire très risquée, pusiqu'il est normal pour quelqu'un de sain mentalement de rejeter une nouvelle technologie sans avoir une bonne raison de s'y intéresser.

Il ne me semble pas avoir répondu de manière semi-aggressive. Par contre, j'ai l'impression que mon refus de me plier à certains dogmes auxquels quelques personnes semblent attachées est vécu par ces dernières comme un affront… Comme je l'ai écrit plus haut, je ne m'attends à rien du tout en publiant ce genre de journal. Je suis développeur freelance, j'adore ça, et j’utilise mon framework pour développer les applications demandées par mes clients, qui en sont d'ailleurs très satisfait. En outre, j'utilise quotidiennement avec délice, professionnellement et à titre privé, plusieurs applications, dont certaines disponibles sur mon site, que j'ai développées et qui sont basées sur mon framework (donc, le dogfooding, je connais). Quelques soient les réactions à mes journaux, elles ne changeront rien à cela, ni d'ailleurs, rassure-toi, à mon intention de continuer à développer ce logiciel et d'autres, dont les évolutions feront l'objet de journaux ici même.

Zelbinium, la programmation ludique

Si tu parles de la possibilité de définir une UI en déclaratif, ya de quoi faire. NeXT/Apple le font depuis le début des années 90, flex le faisant ya 10 ans, Android le fait depuis un bail, qt le fait avec creator et je serais surpris si ms avait pas ca depuis un bail.

J'ai essayé QML (je pense que c'est à cela que tu fais référence avec Qt), et j'ai fait un peu d'Android, mais ça date d'il y a pas mal de temps. Pour Microsoft, il y XAML auquel j'ai jeté un œil, mais cela fait longtemps aussi. Or, il me semble bien que toutes ces technos nécessite une sorte de compilateur. Le mécanisme qui est mis en œuvre dans mon logiciel ne nécessite pas de compilation. Il n'est même pas nécessaire de relancer le logiciel pour voir les modifications. Comme je l'avais écrit dans un des commentaires ci-dessus, j'avais déjà fait quelque chose de similaire, bien que pas aussi poussé, en utilisant XUL, mais je n'ai jamais entendu parler d'un autre logiciel utilisant XUL dans ce but, ce qui n'a rien d’étonnant, vu que XUL n'a guère était employé en-dehors des produits Mozilla.

Si tu parles de la possibilité de modifier le comportement de l'appli depuis du xml, deux choses:
- on a fait plus simple qu'xml pour décrire des comportements
- ça fait un bail aussi qu'on sait que c'est pas une bonne idée (si Apple a jamais porté les bindings d'interface builder sous iOS, c'est pour une bonne raison). C'est un cauchemar à maintenir, et apporte au final tres peu.

XML ne sert qu'à exposer les données, et quelques informations associées, qui doivent être affichées, sans même la moindre indication sur la manière dont ces données doivent être affichées.

Bref, j'ai un peu laissé tomber quand j'ai vu que le nom de l'appli était xdhqxddqt et que t'avais un autre nom de projet a peu près pareil, à 2-3 d/h/x prêt. Ça me donne vachement l'impression d'un inner platform effect si tu veux mon avis.

Avec les applis que je développe pour les clients et mes applis personnels, tous contenant plusieurs binaires, ça fait un paquet de noms à trouver. Aussi, pour ne pas perdre trop de temps avec ça, j'ai établis quelques règles de nommage ; malheureusement, ces règles donnent des noms parfois un peu abscons, mais c’est le prix à payer si l'on veut des noms pas trop longs. Quand à l'inner platform effect, je ne connaissais pas, et, vu ce qu j'ai lu à ce sujet, je ne vois pas trop le rapport entre ça et le nom de mes projets/applis…

Zelbinium, la programmation ludique

Comme je l'ai indiqué au début du journal, l'intérêt du logiciel, en l'état, ne réside pas dans ses fonctionnalités, très limitées pour le moment, mais des technos mis en œuvre. En l’occurrence, l'une dans les technos permet de modifier l'interface graphique du logiciel sans avoir à intervenir sur ses sources. Comme il s'agit d'un logiciel libre, il est censé offrir la liberté de le modifier, et cela par la mise à disposition de ses sources. Avec cette techno, il est encore plus facile d'appliquer cette liberté à son interface, puisque qu'il n'est pas nécessaire de modifier ses sources pour cela. N'ayant connaissance d'aucune autre techno qui offre cette possibilité, et ce site traitant des valeurs attachées au Libre, je pensais que cette techno pouvait intéresser son lectorat, d'où ce journal.

Concernant cette techno, et les autres présentées dans ce journal, toute les affirmations ne sont pas des promesses concernant de futures caractéristiques, mais la description de caractéristiques existantes, et chacun peut s'en persuader en consultant les sources. Je suis conscient que je suis loin d'exceller dans l'art de la communication, et que mes écrits en pâtissent, et c'est pour cela que je m'applique à fournir les réponses les plus pertinentes possibles aux différents points soulevés dans les commentaires.

Que ce soit dans ce journal, ou dans d'autres, on se gausse souvent que j'emploie XML/XSL, ou certaines autres combinaisons de technos, parce que, paraît-t-il, il en existe maintenant de plus récentes pour faire la même chose, mais en mieux. C'est quelque chose que je suis tout à fait prêt à admettre, mais certainement pas uniquement sur la base d'affirmations péremptoires qui ne sont étayées d'aucun élément probant. A titre d'exemple, j'attends toujours que l'on m'indique quelle est cette technologie qui est tellement mieux que XML/XSL(T), et en quoi elle est mieux.

Zelbinium, la programmation ludique

Je ne peux pas être plus précis ; n'ayant quasiment jamais utilisé d'autres framework que le mien, je ne peux pas dire en quoi il se distingue. J'ai juste un jour commencé à coder quelques bibliothèques, regroupant des fonctionnalités que j'utilisais souvent, bibliothèques que je modifie, lorsque c'est nécessaire, pour les rendre plus faciles à utiliser et/ou plus performantes. Puis je leur ai rajouté d'autres bibliothèques, qui prenaient en charge d'autres fonctionnalités que j'avais été amené à implémenter au grès des différents développement que j'ai réalisés, histoire de pouvoir disposer de ces fonctionnalités sans avoir à les réimplémenter. Et c'est l'ensemble de ces bibliothèques qui constitue mon framework. Je n'ai pas cherché à mettre en œuvre des techniques particulières ; la forme que prend l'API est juste celle que je trouve la plus pratique à l'usage. Et la terminologie ci-dessus ne m'est pas suffisamment familière pour pouvoir dire si elle s'applique ou non à l'API de mon framework…

Pour ce qui est du "Hellow World!", c'est un peu le but du logiciel présenté dans ce journal, dans son état actuel, vu le peu de fonctionnalités qu'il implémente. Sinon, pour ce qui est de la technologie que j'appelle XDHTML et qui se concentre sur l'interface graphique, il y le logiciel que je présente à cette adresse : http://q37.info/computing/epeios/apps/xdhdq/.

Zelbinium, la programmation ludique

L'avantage de la transformation XSL, c'est qu'elle est implémentée nativement sur la plupart des navigateurs (en tout cas, les plus populaires). C'est un élément clef dans la technologie que je présente dans ce journal.

Sinon, peut-être parce que je l’utilise quotidiennement depuis de nombreuses années, mais je n'ai aucune difficultés avec XSL ; il faut dire que, probablement parce que j'ai toujours un contrôle total sur le flux XML entrant, je n'utilise que des fonctionnalités relativement basiques.

Zelbinium, la programmation ludique

Quand j'ai écrit ce framework, ce n'est pas parce que j'étais insatisfait de la qualité des logiciels produits de manière classique. La qualité dont je parle est celle perçue par mes clients et dont ils me font part. J'ignore lesquels des points que tu cites ils prennent en compte dans leur opinions qu'ils ont des logiciels que je développe pour eux. Quand à moi, en tant que développeur, je trouve que les bugs de jeunesse sont facilement corrigés, que je n'ai pas de difficulté particulière à faire évoluer mes logiciels, et que la maintenance requiert peu d'efforts. Ceci dit, j'ai peu d'éléments de comparaison, ayant quasiment toujours travaillé uniquement avec mon framework.

Le framewok en question, ça reste un framework C++ ; il n'y a pas de nouveau langage, ou de méta-langage. Donc, un Hello world ! ne différerait pas de manière significative avec la version écrite en C++ standard.

Pour ce qui est de Haïku, je ne connais pas donc je ne saurais dire. Si similitude il y a, elle serait totalement fortuite.

Je sais que je sors des sentiers battus (on me l'a suffisamment fait remarqué dans le journal sur XUL mentionné ci-dessus, d'ailleurs avec le même genre de remarque, mais sur le diptyque XUL/JS) ), mas ça ne m'a pas trop mal réussis jusqu'à présent.

Quoi qu'il en soit, merci pour tes encouragements !

Zelbinium, la programmation ludique

Peut-être que le logiciel a des similitudes avec SàT, mais le projet faisant l'objet de ce journal ne se limite pas à ce seul logiciel.

Ce n'est pas par plaisir de développer ma propre solution que je travaille sur ce projet, mais c'est pour développer une solution qui offre des possibilités qu'aucune autre n'offre.

J'ai étudié des solutions existantes, mais aucune ne répondait à mes attentes. Maintenant, si j'en ai loupée une, je veux bien que l'on me fasse la découvrir. C'est l'un de buts de ce journal, que l'on puisse m'indiquer si, et, le cas échéant, où je me fourvoie.

Zelbinium, la programmation ludique

Comme je l'ai clairement, et à plusieurs reprises, indiqué dans le journal, le logiciel fait peu, très peu, mais pas rien. Et comme c'est précisé dans le titre, ce n'est que le commencement. Il en faut bien un.

Aussi peu qu'il fasse, ça m’étonnerait que ce soit faisable avec des scripts, qu'ils soient à la con ou pas. Mais je ne connais pas tous les langages, alors il est possible que je me trompe, et je serais enchanté d'en apprendre plus sur le sujet.

Comme indiqué dans le journal, on peut télécharger les sources, voire les consulter en ligne, lancer la version Windows de l'application en quelque clics (et quelques commandes saisies dans la console, il est vrai) voire la lancer sur d'autres OS (bon, là, c'est vrai, ce n'est pas aussi simple qu'avec Windows, parce que je ne sais pas faire). Bref, il y a largement de quoi se rendre compte que le framework est loin d'être vide.

Sinon, l'objectif de ce framework est de simplifier le développement d'applications (je ne suis pas masochiste). Et je répondrais volontiers à toute question sur des points qui peuvent paraître obscurs.

Zelbinium, la programmation ludique

Pas la peine de sortir. Le fait est que, bien avant que l'on ne parle de HTML5, j'utilisais XUL pour mes interfaces graphiques. J'ai d'ailleurs écris ce journal à ce sujet. Pour le natif, j’utilisais XULRunner ; par contre, pour le Web, comme seul Firefox était capable d'afficher du XUL, je devais faire une version de l'interface en HTML pour pouvoir l'afficher dans d'autres navigateurs.

Ce que j'appelle XDHTML n'est en fait que ce que je faisais déjà avec XUL, mais en plus avancé, et avec HTML5. Avec l'avantage, cette fois-ci, de pouvoir utiliser le même code pour la version native et la version Web

Zelbinium, la programmation ludique

Ça ne serait pas plutôt :

 struct _item *voisin;

Parce que sinon, la structure se contient elle-même…

Zelbinium, la programmation ludique

Je ne me suis jamais vraiment intéressé à ces histoires de certificats, mais j'ai un serveur sous Debian 8 et, suite à une mise à jour réalisée dernièrement, j'ai trouvé le courrier suivant dans la boite mail du compte root de mon serveur (quelque chose de similaire avait été affiché lors de la mise à jour proprement dite, mais je n'y ai pas vraiment prêté attention) :

ca-certificates (20141019+deb8u1) stable; urgency=medium

  Update Mozilla certificate authority bundle to version 2.6.
    The following certificate authorities were added (+):
    + "CA WoSign ECC Root"
    + "Certification Authority of WoSign G2"
    + "Certinomis - Root CA"
    + "CFCA EV ROOT"
    + "COMODO RSA Certification Authority"
    + "Entrust Root Certification Authority - EC1"
    + "Entrust Root Certification Authority - G2"
    + "GlobalSign ECC Root CA - R4"
    + "GlobalSign ECC Root CA - R5"
    + "IdenTrust Commercial Root CA 1"
    + "IdenTrust Public Sector Root CA 1"
    + "OISTE WISeKey Global Root GB CA"
    + "S-TRUST Universal Root CA"
    + "Staat der Nederlanden EV Root CA"
    + "Staat der Nederlanden Root CA - G3"
    + "TÜRKTRUST Elektronik Sertifika Hizmet Saglayicisi H5"
    + "TÜRKTRUST Elektronik Sertifika Hizmet Saglayicisi H6"
    + "USERTrust ECC Certification Authority"
    + "USERTrust RSA Certification Authority"
    The following certificate authorities were removed (-):
    - "A-Trust-nQual-03"
    - "America Online Root Certification Authority 1"
    - "America Online Root Certification Authority 2"
    - "Buypass Class 3 CA 1"
    - "ComSign Secured CA"
    - "Digital Signature Trust Co. Global CA 1"
    - "Digital Signature Trust Co. Global CA 3"
    - "E-Guven Kok Elektronik Sertifika Hizmet Saglayicisi"
    - "GTE CyberTrust Global Root"
    - "SG TRUST SERVICES RACINE"
    - "TC TrustCenter Class 2 CA II"
    - "TC TrustCenter Universal CA I"
    - "Thawte Premium Server CA"
    - "Thawte Server CA"
    - "TURKTRUST Certificate Services Provider Root 1"
    - "TURKTRUST Certificate Services Provider Root 2"
    - "UTN DATACorp SGC Root CA"
    - "Verisign Class 4 Public Primary Certification Authority - G3"

D’après ce que j'en comprend, on y voit que les certificate authorities USERTrust RSA Certification Authority et COMODO RSA Certification Authority, référencées par les messages retournés par openssl, ont été ajoutées.

Il y a peut-être un problème dans ta procédure de mise à à jour…

Zelbinium, la programmation ludique

Pour les exclusions, il y a raison particulière de ne pas avoir utilisé le même format que gitignore ? Là, le format où tmp signifie en fait un fichier avec une extension .tmp, je trouve ça assez déroutant.

Tout simplement le fait que j'ignorais l'existence de gitignore. Bref, ce n'est pas un format que j'ai exclu sciemment…
Comme pour toutes les autres fonctionnalités du programme, j'ai juste implémenté la première mise en œuvre qui me passait par la tête (pour faire court). Le tmp équivalent à .tmp, c'est juste une facilité que j'ai rajoutée car facile à coder. Maintenant, il faut voir ce que tout cela donne à l'usage, et affiner/modifier en conséquence…

Zelbinium, la programmation ludique

Voir ce commentaire.

Zelbinium, la programmation ludique

fwtchrq se contente de parcourir l’arborescence et d'en comparer le contenu avec une image qu'il en a faite lors d'un précédent lancement. De par les marqueurs qu'il place dans l’arborescence surveillée, il est capable de détecter les créations/renommages/déplacements/suppressions de répertoires. Par contre, concernant les fichiers, vu qu'il s'appuient uniquement sur leur taille et leur horodatage, il rapportera le renommage d'un fichier, par exemple, comme une création et une suppression de fichiers. Pour les mêmes raisons, une permutation de fichiers sera, à priori, rapporté comme une modification de chacun des fichiers

inotify serait, à priori, un bon outil pour détecter un renommage de fichier. Toutefois, j'ai essayé inotifywatch -r sur mon arborescence de test, qui est extrêmement fournie : c'est lent, et, en outre, il n'a pas été en mesure d'aller jusqu'au bout faute d'un nombre suffisant de inode watches. Je suis donc, pour l'instant, dubitatif quand à l'intérêt de cet outil dans le cadre du développement de fwtchrq.

Il y une gestion des exclusions, que l'on spécifie à l'aide d'un fichier, tel que celui que l'on trouve à l'adresse : http://hg.savannah.gnu.org/hgweb/epeios/file/70ebcb4eaa50/tools/fwtchrq/Exclusions.txt. Le fichier d'exclusion à utiliser et à spécifier dans le fichier de configuration, comme on peut le voir à cette adresse (la section en question est en commentaire) http://hg.savannah.gnu.org/hgweb/epeios/file/70ebcb4eaa50/tools/fwtchrq/fwtchrq.xcfg. Lorsqu'un répertoire est exclu, il est vraiment totalement ignoré par le logiciel.

Comme indiqué dans le journal, il ne s'agit là vraiment que d'un tout premier jet. Ce logiciel peut évoluer dans n'importe quelle direction (utilisation de inotify sous GNU/Linux et équivalent pour les autres systèmes, prise en compte d'autres critères que la taille et l'horodatage pour les fichiers, configurabilité de la gestion des exclusions…), pour peu que la demande soit telle que cela vaille la peine pour moi d'y investir le temps nécessaire…

Zelbinium, la programmation ludique

Quel est l'intérêt ? De ce que j'en connais, Git est un logiciel de gestion de version ; or, dans la page dédié à fwtchrq, il y a les liens vers un dépôt Mercurial hébergé sur Savannah contenant les sources de fwtchrq…

Zelbinium, la programmation ludique

L'ennui avec les noms de logiciels, comme avec les noms de domaines d'ailleurs, c'est que, si vous arrivez à en trouver un qui soit assez court, évocateur, joli (quoique l'on puisse entendre par ce terme ; la prononçabilité, par exemple), facile à retenir, etc., et bien, il y des chances que ce nom, ou une forme proche, soit déjà utilisé. Le risque existe alors d'avoir un jour à le changer, avec tous les désagréments que cela implique (modification de tous les documents comportant ce nom), sous peine de risquer un conflit avec une quelconque entité qui utilise un vocable qui présente, ne fût-ce que vaguement, des similitudes avec le nom en question pour désigner l'un de ses produits. C'est déjà arrivé à plus d'un logiciel.

Par ailleurs, je référence mes logiciels sur différents sites, à l'instar, par exemple, de xppq, qui est référencé sur Savannah et Freshcode, pour ne citer que ces deux-là. Pour pouvoir référencer son logiciel sur l'un de ses sites, il faut lui affecter un identifiant unique, et il est pratique alors d'utiliser le nom même du logiciel, comme cela est visible dans les URL ci-avant, plutôt que d'avoir à en trouver un autre, et à devoir se le rappeler, pour chaque site pour lequel cet identifiant est déjà utilisé.

fwtchrq n'est pas le premier logiciel (et, j'espère, pas le dernier non plus) libre que je développe. Et je n'ai pas envie, à chaque fois que j'entreprends de développer un nouveau logiciel, de perdre des heures à chercher un nom qui soit assez court, évocateur, joli, facile à retenir, etc., puis à devoir vérifier qu'il, ou une forme proche, ne soit pas déjà utilisé, découvrir qu'il l'est déjà et avoir à en chercher un autre je ne sais combien de fois, tout en n'ayant jamais la certitude d'avoir poussé mes recherches suffisamment loin pour avoir définitivement écartée l'épée de Damoclès.

Bref, les noms de mes logiciels semblent peut-être biscornus, mais c'est le prix à payer pour avoir une probabilité raisonnablement forte de n'avoir jamais à les changer…

Zelbinium, la programmation ludique

J'ai implémenté un tel système dans mon framework ; j'en ai parlé dans ce journal.
Le système a un peu évolué depuis ; la courte description sur cette page est plus à jour.
L'implémentation en question n'est pas disponible en tant que bibliothèque dédiée, mais les sources étant accessibles, ça peut peut-être quand même être utile…

Zelbinium, la programmation ludique

Je suis actuellement en train de développer une application web, ma première en AJAX, et j'ai bien entendu rencontré le problème des input time/date non implémentés, mais j'ai pu m'en accommoder. Par contre, il y a un autre bug, qui, lui, m'embête bien car je ne vois absolument pas comment le contourner. Et celui-là, en plus d'être apparemment au point mort (plus de trois ans sans nouveau commentaire !), est antédiluvien (il date de 2001 !). Donc, j'ai une application web qui tourne sur tous les navigateurs modernes (y compris Safari), sauf IE (pour autant qu'on puisse encore le qualifier de moderne), Edge (à priori à cause d'un bug qui lui fait exécuter, sans raison, un script en boucle, mais il devrait y avoir moyen de le contourner) et donc, hélas, Firefox…

Zelbinium, la programmation ludique

Quand on achète un ordinateur avec Windows et des crapwares préinstallés, qu'on le reformate pour réinstaller Windows, évidemment sans les crapwares, ou pour installer un autre OS, n'est-ce pas comparable au fait d'aller sur un site web bardé de publicités avec un bloqueur de publicités ?

Je me faisais cette réflexion parce qu'il semble y avoir justement une prise de conscience de certains des acteurs de la publicité sur Internet de leurs abus dans le domaine, et ce suite à la généralisation des bloqueurs de publicités. Peut-être que les responsables des crapwares auront un jour une démarche similaire, pour autant qu'il soit concevable qu'il puisse exister des crapeware respectueux de l'utilisateur, tout comme des publicités non intrusives…

Zelbinium, la programmation ludique

J'ai moi-même installé squirrelmail sur mon serveur, et cela n'a pas été sans mal, ceci pour dire que mes connaissances sont assez limitées dans le domaine, donc ce qui suit est peut-être erroné. Cependant, pour ce que je crois en avoir compris de son fonctionnement, mis à part si on lui demande d'afficher toute la liste des courriers d'une boîte et que ceux-ci soient vraiment nombreux, je ne vois pas trop pourquoi squirrelmail poserait problème, vu que ce n'est pas lui qui gère directement les courriers.
Avec certaines distributions GNU/Linux, le format de stockage de courriers est mbox par défaut, un format dans lequel plusieurs courriers sont stockés dans un seul et même fichier. Donc, avec une boîte mail de 1 Go, on peut se retrouver avec un fichier de la même taille contenant tous les courriers de cette boîte. On peut aisément imaginer que la manipulation d'un tel fichier, notamment pour accéder à un courrier en particulier, puisse prendre un certains temps.
En ce me qui concerne, le format mbox posait problème pour la sauvegarde des courriers. A chaque nouveau courrier qui arrivait dans ma boîte, je me retrouvais à devoir sauvegarder l'ensemble de tous les courriers, même ceux déjà sauvegardés, puisque tous étaient stockés dans un seul et même fichier (mes sauvegardes s'appuient sur rsync). C'est pour cela que je suis passé au format de stockage de courrier Maildir, avec lequel chaque courrier est stocké dans un fichier qui lui est propre, ce qui a évidemment résolu mon problème de sauvegarde.
Maildir ou mbox, ce n'est pas squirrelmail qui gère cela, mais le serveur SMTP (enfin, je crois, et sans doute que le serveur IMAP doit aussi être configuré en conséquence). Face à un problème comme le tiens, je vérifierais d'abord le format de stockage des courriers, parce que si c'est mbox, il y a de fortes chances que le problème vienne de là, et changer de webmail ne le résoudrait en rien.

Zelbinium, la programmation ludique