Logiciel : Sortie de Sunbird 0.3a
Posté par Jean-Yves Beaujean (page perso, ). Modéré le 16 novembre 2005.
Heureusement, elle n'arrive pas les mains vides. Le calcul des événements récurrents a été amélioré ainsi que le support des calendriers distants (via WebDAV), les méthodes d'importation et d'exportation et le stockage des informations à l'aide de SQLite.
Attention, comme spécifié sur le site, il s'agit d'une version de test pouvant contenir de sérieux bugs et provoquer des crashs d'application. Afin que les choses évoluent plus vite pour ce projet, vous pouvez tester Sunbird et rapporter vos bugs. Une page contenant une batterie de tests a été créée à cette adresse : http://wiki.mozilla.org/Calendar:Tests
Note : Sunbird 0.3a est disponible en français pour Linux, Windows et Mac OS X
![[en]](../images/en.png)
Projet Sunbird (2472 hits)-
Release notes (343 hits)
-
Téléchargements (1150 hits)
-
Limitations et Bugs connus (503 hits)
> Lire la dépêche (69 commentaires, moyenne: 2,7).
Vous avez demandé le commentaire #649251.
Run by 
Cette page a été générée par Templeet en 0.0919s (dont 0.0084 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Et les contacts dans tout ça ?
L'IMAP a résolu le problème de sauvegarde des mails (les mails sur un serveur, backupé chaque nuit, même si mon client crash), mais qu'en est-il des contacts ?
Si mon client thunderbird crash et le PC avec, je perds mes contacts !
Comment sauver sur un serveur blindé les contacts qui sont habituellement stockés dans les machines clientes ?
En gros, comment faire du LDAP writable ? ou autre protocole ? Quel client de messagerie sait faire ça ?
Bien sûr, n'importe quelle appli web répond à cette question, mais l'immense majorité des usagers utilisent des applis riches installées en local. La base de contact doit être accessible de manière asynchrone, un peu comme la synchro de Thunderbird en IMAP (qui au passage marche très bien, maintenant).
Pourquoi personne n'aborde jamais ce sujet ? Vous êtes tous sous mutt + abook + rsync ?
[^]Re: Et les contacts dans tout ça ?
http://absync.alternc.org/
en cours de packaging, mais le plugin fonctionne pour les fous qui ont le temps de se configurer un squirrelmail + advanced addressbook + sync.php ... bref, pour l'instant c'est pas fini pour les end-users, mais pour les geeks, ca marche :)
[^]Re: Et les contacts dans tout ça ?
C'est bien beau cet ensemble de plugins, mais ça reste du patchage. Il y a déjà une manière reconnue de conserver les "carnets d'adresse" (à la base c'est plus un répertoire d'entreprise) sur un serveur, LDAP.
On a déjà LDAP qui est intégré à Thunderbird et dont on a un plugin pour Squirrelmail.
Il ne suffirait que de pouvoir écrire à partir de Thunerbird sur le serveur LDAP comme le suggérait Nicolas Ecarnot plus haut.
[^]Re: Et les contacts dans tout ça ?
- Pas possible de lister les contacts de ton carnet LDAP distant dans thunderbird
- Pas possible de voir hors ligne les contacts de ton carnet LDAP
- Pas possible de modifier une fiche du carnet ldap distant depuis thunderbird ...
Sinon oui, ldap c'est LA solution hein :-D
Soyons sérieux ...
[^]Re: Et les contacts dans tout ça ?
- Pas possible de lister les contacts de ton carnet LDAP distant dans thunderbird
Si. Tu mets "*" et ca liste chez moi.
- Pas possible de voir hors ligne les contacts de ton carnet LDAP
Si. Tu fais une synchronisation locale de ton serveur. Il suffit d'avoir les droits suffisants.
- Pas possible de modifier une fiche du carnet ldap distant depuis thunderbird ...
Ca c'est un problème de Thunderbird. Il suffirait d'implémenter l'écriture sur LDAP. J'utilise le plugin Turba pour Horde qui le fait très bien. On peut en plus gérer plus annuaires (un partagé, un personnel).
Sinon oui, ldap c'est LA solution hein :-D
Soyons sérieux ...
Ah ca c'est de l'argument qui tue :). J'utilise justement une solution de ce type et c'est très satisfaisant. Webmail Horde dans la journée qui fonctionne très bien avec IMAP/LDAP, et Thunderbird chez moi avec IMAP et LDAP en lecture seule.
Ce qui manque donc principalement c'est l'écriture sur LDAP. Ca ne doit pas être si terrible à implémenter, le problème étant plutôt que ca ne concerne surement pas assez de monde (pour l'instant).
--
Thomas
[^]Re: Et les contacts dans tout ça ?
Précision : cette extension pour Thunderbird permet donc d'en synchroniser le carnet d'adresses avec celui de SquirrelMail, via un plugin remplaçant le carnet d'adresses par défaut. Le nouveau carnet utilise une base MySQL, et propose des champs équivalents à ceux de Thunderbird.
[^]Re: Et les contacts dans tout ça ?
C'est vrai qu'une gestion centralisée des contacts manque énormement. Je cherche aussi une solution depuis longtemps.
Il faudrait aussi pouvoir partager les contacts. Pour une petite structure je n'ai pas trouvé le moyen de le faire.
La solution est vraisemblablement ldap. Pratiquement tous les clients email le gère. Par contre il n'y a jamais la possibilité d'ajouter un contact dans la base ldap à partir de ces clients. L'écriture dans une base ldap est-elle tellement compliquée?
[^]Re: Et les contacts dans tout ça ?
Pour l'avoir déjà fait dans JMail, oui je peux confirmer que l'écriture dans LDAP, c'est pas super simple, mais c'est faisable.
Le gros problème avec LDAP (en tous cas y a 2-3 ans), c'est que c'est super chiant à bien configurer côté client. Alors faire un truc qui marche avec tous les serveurs LDAP, ben c'est pas évident..
[^]Re: Et les contacts dans tout ça ?
Le meilleur moyen c'est sans doute un plugin de synchro qui synchronise base contacts client mail avec base (mysql / ldap ..) contacts sur un serveur.
En mode non connecté on a qd même la liste de ses contacts.
En mode connecté on peut sauvegarder ses contacts sur le serveur via la synchro.
Cela existe pour Outlook, doit certainement exister pour thunderbird (cf commentaire plus haut) et avec d'autres ...
http://www.paulla.asso.fr
[^]Re: Et les contacts dans tout ça ?
>Le meilleur moyen c'est sans doute un plugin de synchro qui >synchronise base contacts client mail avec base (mysql / ldap ..) >contacts sur un serveur.
On a pas forcément la main sur le serveur LDAP/SQL pour avoir les droits d'écriture.
Par contre dans un folder IMAP si.
On peut même faire des folders partagés avec les acls qui vont bien.
[^]Re: Et les contacts dans tout ça ?
Oui effectivement, on a rarement les droits d'écriture sur le serveur LDAP de l'entreprise..
[^]Et les contacts -> dans IMAP
Et pourquoi pas mettre les contacts dans un dossier d'E-MAIL sous IMAP à la manière du système de fichier GMAILFS ?
On aurait un nom de dossier IMAP avec un nom prédéfinis et chaque email dedans serait un contact. Pas de problème pour l'écriture et l'utilisation hors ligne. Au niveau du serveur, on ne change rien. Il y a "juste" à modifier le client pour qu'il cache ce dossier dans la liste des dossier IMAP et le transforme en liste de contact.
C'est même valable pour des comptes POP3, il suffit de conserver ses contact sous forme de mail en local.
Qu'en pensez vous ?
[^]Re: Et les contacts -> dans IMAP
C'est le principe utilisé par Kolab
http://www.kolab.org/doc/kolabformat-2.0rc3-html/index.html
Un dossier "calendar" qui contient un "mail" par entrée dans le calendrier, ce qui permet de gérer facilement les synchronisations, la prise en compte de nouvelles entrées, le mode hors ligne, etc ...
Idem pour les notes, contacts, et tâches.
C'est extrèmement efficace, et ca évite de rajouter des SGBD là où ils se justifient peu, ou d'utiliser LDAP comme le SGBD qu'il n'est pas (voir LDAP avec un backend SGBD pour pousser le vice à fond).
Non-accessoirement on centralise les données à un seul endroit et la gestion des ACL par le serveur IMAP permet des choses sympathiques.
On peut faire plus compliqué mais je cherche encore l'interêt.
M
[^]Re: Et les contacts -> dans IMAP
Et vous trouvez pas ça "crade" comme solution, franchement ?
Stocker les contacts dans des mails que le client cache..
[^]Re: Et les contacts -> dans IMAP
Oui et non.
Finalement, utiliser le systême d'archivage des mails pour stocker toutes les informations est une idée relativement propre. Le protocole est simple et robuste (IMAP, POP3). Il n'y a pas besoin de changer les serveurs ni d'en mettre d'autres.
Ce serait plus propre de définir encore un autre protocole et de faire tourner un serveur de plus ?
L'idée d'UNIX est que tout est fichier. Pourquoi pas reprendre cette idée au niveau du lecteur de courriel et dire que tout est mail ?
Moins de code, moins de serveur -> moins de bogues et plus de puissance pour faire autre chose.
[^]Re: Et les contacts -> dans IMAP
"C'est extrèmement efficace, et ca évite de rajouter des SGBD là où ils se justifient peu"
ALors dis moi juste comment tu geres :
- les evenements lies a plusieurs personnes (et toutes les problematiques associees)
- les evenements recurrents
- ...
Avec ce modele, l'affichage du calendrier d'une personne (et quasiment toutes les operations) necessite de lire tous les fichiers evenements de son agenda.. super efficace. Pour afficher une petite vue semaine, je dois lire 2000 fichiers.
Pour inserer un rdv et avertir des conflits, idem (et alors un rdv sur plusieurs utilisateurs...), pour avoir les vues des disponibilites idem..
Alors Imaginer en plus les vues multi-utilisateurs...
De meme pour les synchros.
Et quand tu fais ca sur le serveur, ll faut pas s'etonner que ces solutions supportent mal la montee en charge.
Avec un modele BD bien pense (ce qui n'est pas trivial), toute consultation meme complexe peut repondre au doigt et a l'oeil, meme avec un tres grand nombre de users et d'evenements.
Ca fait plus de 3 ans qu'on bosse sur ces modeles.
Le modele BD est utilise par obm (http://obmpro.aliacom.fr) avec plusieurs installations de plusieurs milliers d'utilisateurs (dont 30 000 sur 1 serveur).
Des connecteurs pour Outlook et Evolution sont imminents. Ils permettent de synchroniser les evenements, les contacts et les taches.
Avec une BD centrale qui peut renseigner un LDAP ensuite utilise par les clients comme carnet d'adresse.
[^]Re: Et les contacts -> dans IMAP
Et ca marche en mode déconnecté ?
En effet, les portables voyagent de plus en plus (c'est fait pour çà) et les personnes les utilisent très souvent sans réseau.
L'idée derrière l'IMAP avec copie locale (ou POP3) est de pouvoir tout faire même si on n'a pas le réseau.
[^]Re: Et les contacts -> dans IMAP
Oui ca marche en mode déconnecté.
Le connecteur Evo marche lui en déconnecté ou en direct.
[^]Re: Et les contacts -> dans IMAP
Je penses que tu as répondu un peu vite car tu juges avec des postulats qui sont faux.
Dans Kolab, IMAP est un entrepot qui sert à la synchronisation, mais que l'on ne parcoure pas en permanence (et heureusement). Tu confonds peut être avec d'autres outils.
Ca n'induit presque pas de charge coté serveur contrairement à ce que tu dis, pour la bonne raison que le choix de Kolab est de décentraliser les tâches "gourmandes" du coté du client (principe du "smart client"), en utilisant (entre autres) les flags IMAP qui permettent de ne lire que les nouveaux éléments.
Ce concept de "délégation des travaux au client", y compris avec des machines peu puissantes est très efficace. Et sur des machines modernes, c'est carrément transparent.
Accessoirement on profite des capacités du mode déconnecté IMAP. En fait c'est simple : gérer un agenda partagé avec Kolab n'entraine absolument pas plus de charge que la gestion d'une boite mail classique sans agenda (et je parle d'agendas à plusieurs dizaine de milliers d'entrées). Coté montée en charge Cyrus-IMAP n'a plus grand chose à prouver, et sans même avoir à utiliser ses capacités d'indexation.
Je ne doute pas des qualité de la solution que tu défends, mais je n'ai pas envie de jouer à celui qui a le plus gros serveur j'avoue ;)
Simplement, ne t'en fais pas pour les capacités de Kolab à gérer plusieurs dizaines de milliers de compte sur un serveur unique (même si je prefère sa capacité de gestion de serveurs maîtres et esclaves que je trouve simple et élégante).
Pour terminer, je connais un peu la solution OBM, et ca ne correspond en effet pas à la solution à laquelle je pensais en disant "SGBD mal utilisé". Il n'était pas utile de se sentir agressé :)
En fait je suis d'accord avec toi sur pas mal de points, mais ca ne s'applique tout simplement pas à ce dont je parlais !
Bise ;)
M
[^]Re: Et les contacts -> dans IMAP
Tout d'abord, pas de soucis, je ne me suis pas senti agresse, juste qu'on entend un peu trop que serveur d'agenda en libre = webdav + ical (et par exemple stocke sur imap) car c'est loin d'etre le plus efficace pour cette tache et surtout ce n'est pas le gros de la problematique (sachant que webdav est essentiellement un transport et que importer ou exporter du ical est une tache simple par rapport au reste).
"Dans Kolab, IMAP est un entrepot qui sert à la synchronisation, mais que l'on ne parcoure pas en permanence (et heureusement). Tu confonds peut être avec d'autres outils."
Je parlais de ce type d'outils de facon generale, comme les Open* par exemple.
"IMAP est un entrepot qui sert à la synchronisation, mais que l'on ne parcoure pas en permanence...
délégation des travaux au client..."
Comment Kollab traite :
- la recherche de conflits lors la creation d'evenements sur plusieurs utilisateurs
- la recherche de plage disponibles pour un groupe d'utilisateur
- Soit il interroge le serveur IMAP (pour avoir les agendas des utilisateurs references), donc travail important pour un serveur IMAP, puis transfert de pas mal de donnees pour traitement sur le client
- soit Kollab stocke tout sur le client, mais dans ce cas il faut s'assurer que les agendas des utilisateurs stockes en local sont bien a jour. Donc bcp de stockage sur le client (car potentiellement on peut inviter tout user a un rdv) et bcp de synchros !
ou autre methode ?
"gérer un agenda partagé avec Kolab n'entraine absolument pas plus de charge que la gestion d'une boite mail classique"
Pour un agenda mono-utilisateur, je suis d'accord.
Mais pour du multi-utilisateur plus du tout. Tu peux multiplier par le nombre d'utilisateur avec qui tu echanges (invites, participants, utilisateur dont tu as le droit de lecture ou deleguation d'agenda,..)
On utilise et apprecie beaucoup Cyrus-Imap, notamment pour sa capacite a gerer de gros volumes.. de mail. C'est juste que le modele d'un mail, n'est pas celui d'un rdv (plusieurs participants, recurrences,..) et que les demandes a un serveur d'agenda ne sont donc pas les memes.
D'ailleurs le modele 1 rdv = 1 mail n'est pas nouveau et est le modele utilise par Outlook / Exchange.
Mais quand on regarde dans ces entrailles... waow la cata ! 1 mail (sens ms) c'est pres de 100 proprietes, variables selon plusieurs criteres (sans parler de la non documentation bien entendu)
je suis content que tu ne visais pas obm en disant sgbd mal utilise ;) vu le temps qu'on y a passe ! mais toute discussion constructuve est la bienvenue.
Amicalement
[^]Re: Et les contacts dans tout ça ?
Le meilleur moyen c'est sans doute un plugin de synchro qui synchronise base contacts client mail avec base (mysql / ldap ..) contacts sur un serveur.
Ce que fait donc ABSync dont Benjamin parle plus haut
[^]Re: Et les contacts dans tout ça ?
Pour info, pour ceux qui veulent suivre de plus près l'avancée de cette question dans TBird :
https://bugzilla.mozilla.org/show_bug.cgi?id=124897
[^]Re: Et les contacts dans tout ça ?
Le moins que l'on puisse dire c'est qu'ils sont actifs :)