Journal Faisabilité XUL

Posté par  (site Web personnel) .
Étiquettes : aucune
0
13
août
2004
Bonjour,

Je fais appel à ceux ayant déjà bidouillé en Mozilla XUL : quelle est, selon vous, la difficulté de mise au point d'une version dépouillée de Thunderbird pour qu'elle puisse être exécutée à travers le réseau à la place d'un webmail classique ?

(Je me pose aussi la même question pour Calendar/Sunbird.)

Merci.
  • # Thunderbird est en XUL...

    Posté par  (site Web personnel) . Évalué à 4.

    Thunderbird étant en XUL, il y a peut être du code à reprendre là dedans pour ce genre d'application. J'ai même lu par ci par là qu'on pouvait lancer l'interface de Thunderbird dans Firefox avec la bonne url chrome://, mais que vu que c'est pas prévu pour, ce n'es pas très stable.

    En tous cas si tu arrives à des résultats probants n'hésite pas à en faire part, ça peut être très intéressant.
  • # D'accord avec toi

    Posté par  (site Web personnel) . Évalué à 3.

    Je ne sais pas vraiment mais l'idée m'était déjà passer par la tête. Ca serait idéal pour faire un client groupware en ligne, accessible depuis toute machine possédant un navigateur gecko. Ca permettrait de déplacer l'antispam adaptatif de thunderbird coté serveur et de classer les spams dès qu'ils arrivent (et non pas dès qu'on se connecte).
  • # je crois que ça va pas être possible

    Posté par  . Évalué à 2.

    le thunderbird light (tiens, sympa comme nom) essaiera d'accéder au système de fichier local et échouera car le XUL est sûrement exécuté en environnement protégé. De plus je ne pense pas que thunderbird soit intégralement en XUL, il y a sûrement une grande partie de code binaire compilé, non ? Enfin bref à mon avis il faut tout reprendre depuis le début, à la limite copier l'interface XUL mais c'est tout...
    • [^] # Re: je crois que ça va pas être possible

      Posté par  . Évalué à 6.

      pour préciser un peu ma pensée, et bien que je ne maitrise pas toutes ces technos, XUL est un language permettant de créer des applications riches exécutées coté client, et non pas un genre d'application exécutée sur le serveur. Pour tout ce qui est intéraction avec le serveur, il faudra donc utiliser des scripts coté serveur, appelés depuis l'interface XUL via HTTP. Tout le fonctionnement interne d'accès aux données est donc à refaire.
      • [^] # Re: je crois que ça va pas être possible

        Posté par  (site Web personnel) . Évalué à 5.

        c'est tout à fait ça
      • [^] # Re: je crois que ça va pas être possible

        Posté par  (site Web personnel) . Évalué à 2.

        Oui en gros, il faut récrire tous les accès aux ressources locales sous forme d'appels réseaux (xml-rpc ou SOAP) et que le serveur/backend s'occupent des traitements correspondants. Ca doit faire pas mal de boulot.
        • [^] # Squelette

          Posté par  . Évalué à 1.

          Je ne sais pas exactement comment fonctionne IMAP, mais il me semble que le but est deja de laisser les mails sur le serveur et de les consulter par le réseau. (Note:comme j'ai jamais essayé, je peux me tromper completement)

          Si c'est ca, y aurait pas moyen de reprendre comme base le fonctionnement du client mail avec IMAP comme squelette et "juste" réécrire les appels IMAP vers SOAP ?
          Evidemment, il y a en face le wrapper sur le serveur qui va, lui, vraiment partir vers IMAP à la manière d'un webmail classique...

          Par la suite, coder les règles de spamassassin (ou autre) du serveur a partir du TB light...

          Ca parait jouable... non?
          • [^] # Re: Squelette

            Posté par  (site Web personnel) . Évalué à 2.

            Disons qu'il faudrait développer une architecture 3 tiers:

            [Client XUL/Mozilla] <---SOAP/Http---> [Backend PHP ou Zope] <--IMAP--> [Serveur IMAP + Filtre AntiSpam]

            On peut éventuellement utiliser SpamAssassin (ou autre) sur le serveur IMAP (ou plutot en amont au niveau du MTA) et adapter les boutons junkcontrol de l'interface XUL pour qu'il se contente de déplacer les spams dans un répertoire IMAP prévu pour recuillir le spam pour l'algo d'apprentissage. On peut aussi imaginer de déporter le moteur antispam de thunderbird sur le backend et qui s'occupe lui même de trier les mail sur le serveur IMAP.

            Il faudrait aussi penser à la gestion du carnet d'adresses : Si l'on souhaite utiliser un serveur LDAP, ou place t'on le client LDAP : au niveau du [Client XUL/mozilla] ou au niveau du [Backend PHP ou Zope]. Je ne sais plus si mozilla XPFE dispose d'un client LDAP en standard. Si oui, il suffit de l'utiliser, si non il faudrait l'embarquer sous forme de XPI mais ca impose des problèmes de gestion des droits. Dans ce cas il vaudrait mieux installer le client LDAP au niveau du backend et le controler à distance par SOAP/http.

            Perso ca me parait jouable. Mais ca doit faire pas mal de boulot quand même :)
      • [^] # Re: je crois que ça va pas être possible, stub à la CORBA ?

        Posté par  . Évalué à 2.

        Idée comme ca :
        XUL+JS -> si il y a moyen de déporter tous les appels vers le serveur avec des stub un peu à la manière de CORBA, il n'y a pas besoin de tout récrire.
        Le problème :
        - faisabilité comparé à la réécriture
        - vitesse d'exécutation/consommation bande passante...
        - sécurité (le "save as" sauve les données sur le disque du serveur ...)

        En tout cas, ça serait rigolo de pouvoir retrouver son mail/calendrier/autre de n'importe où.
        • [^] # Re: je crois que ça va pas être possible, stub à la CORBA ?

          Posté par  (site Web personnel) . Évalué à 2.

          SOAP ou xmlrpc sont +/- des équivalents de corba qui utilisent des requetes http (firewall-friendly) et sont donc plus adaptés que CORBA pour faire une appli web. Mais pour le reste, c'est grosso modo pareil (client - stub <---Network---> stub- server). De plus Mozilla inclus de base une lib pour faire des clients SOAP ou xmmlrpc.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.