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.
[^] # Re: Et les contacts -> dans IMAP
Posté par bohzi . En réponse à la dépêche Sortie de Sunbird 0.3a. Évalué à 1.
"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