Journal Faisabilité XUL

Posté par Christophe GRAND (site web personnel) le 13 août 2004 à 11:45.

Étiquettes : aucune

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 scand1sk (site web personnel) le 13 août 2004 à 12:00. É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 Olivier Grisel (site web personnel) le 13 août 2004 à 13:02. É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 Nap le 13 août 2004 à 13:17. É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 Nap le 13 août 2004 à 13:20. É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 Laurent J (site web personnel, Mastodon) le 13 août 2004 à 13:30. Évalué à 5.
    
    c'est tout à fait ça
  - [^] # Re: je crois que ça va pas être possible
    
    Posté par Olivier Grisel (site web personnel) le 13 août 2004 à 14:16. É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 Seazor le 13 août 2004 à 15:12. É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 Olivier Grisel (site web personnel) le 13 août 2004 à 15:31. É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 _alex le 13 août 2004 à 21:19. É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 Olivier Grisel (site web personnel) le 14 août 2004 à 00:01. É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.