Forums : Les possiblités de la plateforme Mozilla

XUL décrit une interface utilisateur. Ton service Web délivre surement de l'information provenant d'une base de données.

Il faut donc que ton code XUL aille chercher cette information par des requêtes adaptées (source RDF, AJAX, SOAP, etc.) et l'affiche à l'utilisateur en dynamique.

Faire du XUL en dynamique, c'est mal je pense. Et de toutes façons, l'utilisateur pourra toujours voir le code (DOMi, firebug, CTRL+U, etc.)

Merci pour ta reponse. En fait, c'est bien l'application cliente qui est originale, par sa forme mais surtout par les fonctionnalités qu'elle propose. Il n'y a pratiquement aucun echange avec mon serveur (si ce n'est l'authntification). Ce client pourrait donc fonctionner ailleurs, et je voudrais pouvoir l'empecher.

Est-ce que je peux envisager d'avoir un squelette fait en XUL qui executerait d'autre bout de code XUL recupéré sur mon serveur ?

Meme si c'est contournable, ca peut quand même devenir fastidiueux de reconstituer l'appli complete si les bouts sont nombreux ?

Merci.

L'interface XUL en elle-même tu ne pourras pas cacher son code-source même en feintant avec du XUL downloader depuis ton serveur, après tout ce n'est qu'une interface il ne doit rien y avoir de secret-defense dedans. Par contre, si le plus interressant dans ton application ce sont des fonctions, tu peux peut-être les écrire en c++ avec XPCOM, ainsi tu ne livres qu'un fichier binaire illisible pour un humain qui n'as pas le code source. L'inconvénient c'est que tu devras livré ton composant XPCOM compilé pour chaque OS (Windows, Mac, Linux...). Ça répond à ta question ?

David

Oui merci ca repond à ma question. Je trouvais que l'interet de XUL c'etait la facilité pour le deploiement et les MAJ et le fait que cela soit multiplateforme.

Là si je doit livret un composant en plus je perd tous ces interêts !

Je vais plutot m'orienté vers Java, ce n'est pas parfait non plus mais il y a quand meme des mecanismes d'obfuscation pour eviter que l'on pompe le code source d'un application ou d'un applet.

Quand tu dis "une interface il ne doit rien y avoir de secret-defense dedans". Il n'y a rien de de secret, non, mais si tu veux vendre un produit et qu'en 10 secondes quelqu'un peut le copier, tu ne vas pas le vendre longtemps. La plupart des applis que l'on utilise n'on rien de revolutionnaire mais refaire l'implementation prends du temps, c'est pourquoi on peut les vendre et que certains sont près à les acheter ...

Un composant XPCOM écrit en c++ n'empêche pas le deploiement et les MAJ de ton application. L'avantage du framework mozilla c'est de n'avoir à écrire le code-source de ton composant c++ qu'une fois, c'est le multi-plateforme comme tu l'as remarqué. Le fait de devoir compiler ton composant pour chaque OS n'est pas une restriction de mozilla mais de C++ lui-même. J'ai pas d'exemples à te fournir mais cette solution du composant XPCOM en c++ est utilisé par des devs qui veulent masquer une partie de leur code-source.

mais si tu veux vendre un produit et qu'en 10 secondes quelqu'un peut le copier, tu ne vas pas le vendre longtemps

on se demande bien comment font les boites qui vivent du logiciel libre (dont celle où je travaille), en particulier celles qui vendent des distributions linux ;-)

Faut bien comprendre qu'il n'existe aucune protection contre la copie... D'ailleurs, l'offuscation du code source n'empêche pas la copie. Rien n'empêche en java de copier les .jar sur n'importe quel poste.