(j'ai l'impression que tu me prends pour un c...;-)
Tu m'expliques que c'est un principe de base de KDE, super, ça ne solutionne pas le problème de définir des contrats entre ces composants permettant à la fois d'être souple, tout en restant implémentable. C'est un problème récurrent en IT depuis ... le tout début. Pratiquement: au plus ton contrat est précis et poussé, au plus il sera spécifique et limite le type d'échange possible. Arrives-tu a imaginer des documents s'intégrant dans d'autre autre que des image, du texte et des tableaux? j'ai du mal.
Ton exemple d'HTML est intéressant, c'est justement quelque chose de très difficile à intégrer sur un document papier, prend par exemple les hyperliens, comment doivent-ils se comporter dans un document KWord? ouvrir le lien dans une nouvelle fenêtre? rester dans la même? que dire d'un composant HTML dans un shape, au forme bizaroide? ça doit suivre les contours? la mise à l'échelle ça fait un zoom graphique ou ça ne change que la taille du texte? etc... J'ai un peu l'impression de lire "on vous donne des Shape, théoriquement on peut tout faire dans un shape, donc on vous fournit une techno super révolutionnaire qui permet de tout faire!".
Quand je parle de versionning, je ne parle pas de versionning de document, mais de composant, comment t'assurer que tu instancies bien la bonne version de ta classe? celle de KWord 1.1 et pas celle de KWord 1.2 qui n'est pas totalement compatible? Pense au problème de la gestion de paquet, imagine que tu pourrais avoir encore pire... Imagine aussi le cas d'une application intégrant deux composants... mais utilisant des versions différente d'une certaine libraire, out-of-process, c'est possible, in-process... ouais en fait théoriquement ça l'est ;)
Voilà, ça veut pas dire que c'est une mauvaise idée, que c'est nul, que c'est pas bien, et surement pas que je ferais mieux, plutôt que je suis curieux de voir comment seront adresser ces différents problèmes, qui sont bien réel (si tu veux des exemples de ma vie de tous les jours, c'est quand tu veux ;). Bref, tout comme KDE4, je suis intéressant, et curieux de voir ce que ça va donner!
[^] # Re: intérêt
Posté par tene . En réponse au journal Un regard sur KOffice 2.0. Évalué à 5.
Tu m'expliques que c'est un principe de base de KDE, super, ça ne solutionne pas le problème de définir des contrats entre ces composants permettant à la fois d'être souple, tout en restant implémentable. C'est un problème récurrent en IT depuis ... le tout début. Pratiquement: au plus ton contrat est précis et poussé, au plus il sera spécifique et limite le type d'échange possible. Arrives-tu a imaginer des documents s'intégrant dans d'autre autre que des image, du texte et des tableaux? j'ai du mal.
Ton exemple d'HTML est intéressant, c'est justement quelque chose de très difficile à intégrer sur un document papier, prend par exemple les hyperliens, comment doivent-ils se comporter dans un document KWord? ouvrir le lien dans une nouvelle fenêtre? rester dans la même? que dire d'un composant HTML dans un shape, au forme bizaroide? ça doit suivre les contours? la mise à l'échelle ça fait un zoom graphique ou ça ne change que la taille du texte? etc... J'ai un peu l'impression de lire "on vous donne des Shape, théoriquement on peut tout faire dans un shape, donc on vous fournit une techno super révolutionnaire qui permet de tout faire!".
Quand je parle de versionning, je ne parle pas de versionning de document, mais de composant, comment t'assurer que tu instancies bien la bonne version de ta classe? celle de KWord 1.1 et pas celle de KWord 1.2 qui n'est pas totalement compatible? Pense au problème de la gestion de paquet, imagine que tu pourrais avoir encore pire... Imagine aussi le cas d'une application intégrant deux composants... mais utilisant des versions différente d'une certaine libraire, out-of-process, c'est possible, in-process... ouais en fait théoriquement ça l'est ;)
Enfin la gestion d'erreur est problématique, si ton composant est in-process et plante, ton appli peut (et va en fait, surtout en natif) crasher avec. Imagines que je t'envoie un document et qu'il fasse planter ton traitement de texte, tu penserais quoi? qu'il te suffit de ne pas l'utiliser? Pourtant, je te garantis, "chez moi ça marche"©®. L'avantage de faire du out-of-process, est que l'os te garantit plus ou moins bien l'intégrité de ta mémoire, réimplémenter cela de façon efficace est légèrement plus complexe in-process (voir impossible). Imagine pire: un copier coller dans ton document "design à pondre pour hier version totalement presque final" qui fasse planter l'appli, pas de bol, la sauvegarde automatique est passée par là... pourquoi tu crois que c'tait une mauvaise idée de permettre l'utilisation d'ActiveX depuis ms-word? :p
Voilà, ça veut pas dire que c'est une mauvaise idée, que c'est nul, que c'est pas bien, et surement pas que je ferais mieux, plutôt que je suis curieux de voir comment seront adresser ces différents problèmes, qui sont bien réel (si tu veux des exemples de ma vie de tous les jours, c'est quand tu veux ;). Bref, tout comme KDE4, je suis intéressant, et curieux de voir ce que ça va donner!