[ 1 2 3 4 5 6 7 8 9 10 :: Suivant ]
Re: OBM-* & Calendar
Et en plus OBM a pour moi un sacré malus: les connecteurs sont close-source et payants.
Le code du serveur de synchro est en svn ici : http://svn.obm.org/svn/obm-sync/trunk et celui du connecteur lightning est sur http://svn.obm.org/svn/obm-mozilla-calendar/trunk donc tout est bien libre (sauf la partie outlook pour l'instant).
[ Répondre ]
Miliconvert
La même équipe que Milimail développe aussi le projet miliconvert http://miliconvert.org/ dont l'objectif (résumé) est de créer un altova mapforce like, c'est à dire un outil transformations XML, en libre.
Bien que la roadmap passe par des formats militaires pour valider le fonctionnement de l'outil, la transformation de tout format défini par un XML Schema est possible. Ce projet est interessant car peu de logiciels libres couvrent le périmètre d'altova mapforce ou stylus studio. Le logiciel est basé sur eclipse, est dispose ainsi de toutes les possibilités d'extension par plugins de cette plateforme.
[ Répondre ]
Soulagement énorme pour les développeurs Java
Aujourd'hui, Java et MySQL ne font pas bon ménage : les timestamps mysql sont limités en [1970-2038] (avec des datetime ca marche...), leur précision est en seconde et non en millisecondes, et pas mal de choses implicites en Java du genre unicode et transactions sont optionnelles sur mysql.
Pour moi, développeur java devant greffer régulièrement des applications sur des bases mysql existantes, c'est une super nouvelle. A mon avis la première choses que sun va faire, c'est faire de MySQL une base supportant le minimum de fonctionnalité imposé par JDBC.
Aujourd'hui, mon quotidien avec mysql, c'est lutter avec des détails obscurs de configuration du type (extrait de la doc du driver jdbc mysql) :
useGmtMillisForDatetimes : Convert between session timezone and GMT before creating Date and Timestamp instances (value of "false" is legacy behavior, "true" leads to more JDBC-compliant behavior. default : false
Avec un peu de chance (pour moi), certains réglages "par défaut" de mysql vont changer de valeur...
[ Répondre ]
Re: ...et LemonLDAP
LemonLDAP est évoqué dans la présentation FederID de Clément.
[ Répondre ]
Re: Surprise
La DGA a-t-elle dans ses autres cartons d'autres projets comme ça ? Un Milifox, un Milioffice, un Milignome ? SourceForge a du souci à se faire, l'armée française est dans la place !
Oui, ils ont aussi le projet miliconvert http://admisource.gouv.fr/projects/miliconvert/
Il s'agit d'un mapper graphique xsd -> xsd, un peu comme altova mapforce, mais implémenté sous la forme de plugin eclipse basé sur GEF et XSD.
[ Répondre ]
Re: [mode="arrogant"] ;-)
Si l'on parcours bien la news on remarque que clamav détecte 100% des virus sur le tests mis en valeur. Ce test porte sur 18 virus.
Si tu clicke sur le lien vers le test PC mag, ce dernier porte sur 606000 virus différents. Sur ce panel bcp plus exhaustif, clamav se place dans... les 3 derniers, avec 63% de détection.
[ Répondre ]
Re: documentation ?
C'est très dépendant du projet et fait plutot parti de notre offre de service que de obm.
Classiquement on configure la passerelle pour délivrer les mails en double sur le nouveau et l'ancien serveur de messagerie. On réutilise aussi des "bouts de code" de notre connecteur outlook migrer les anciennes données. Pour groupwise, je ne serai pas utilisateur régulier d'évolution je ne saurai pas que ça existe : jamais vu chez un client.
[ Répondre ]
Re: documentation ?
Il y a un manuel d'installation des parties obm-mail/obm-ldap mais il n'est pas vraiment dans un état diffusable.
Pour ce qui est de l'utilisation d'autres serveurs, c'est très difficile. Un automate se charge d'analyser la base de données de obm et de propager les infos pertinentes pour la messagerie dans un annuaire openldap.
L'automate reconfigure ensuite les paramètres des services qui ne peuvent être pris dans ldap : création / destruction de boîtes aux lettres en utilisant les API de cyrus, application des ACLs sur les bals, mise à jour des quotas, mise à jour des filtres serveurs pour le vacation / .forward. Des démons réseaux sont installés sur les serveurs postfix pour réécrire certains paramètres de configuration.
Il est (très) théoriquement possible de faire évoluer l'automate pour supporter d'autre serveurs libres, mais l'intérêt pour nous est limité / inexistant : notre effort de r&d est axé sur "la fourniture d'un chemin de migration de outlook + echange vers une solution 100% libre". Notre solution ne vise absolument pas à concurrencer des outils type webmin.
[ Répondre ]
Re: documentation ?
Le service messagerie est fourni par cyrus imap, postfix et openldap. Si tu a installé uniquement la partie php, tu n'aura aucune fonction liée à la messagerie. Avec l'installation basique tu peux utiliser le calendrier Ajax et la partie crm.
L'installation complète avec l'annuaire, les services de messagerie est un peu plus "touchy".
[ Répondre ]
Re: infos
A la St Glin Glin :O)
Ou pas : http://dbmjui.sf.net/cal_sub.png ou encore http://dbmjui.sf.net/evo_cal_0.7.png
Le code a besoin d'être porté sur les dernières api de evolution-data-server et du web-service de obm, mais il existe ;-)
[ Répondre ]
Re: Interopérabilité
il y a un export icalendar des calendriers. L'import devrait arriver dans la 2.1.0.
Pour imap, ben... c'est thunderbird, outlook, mutt, evolution & co les connecteurs ;-)
[ Répondre ]
Re: connecteur Outlook
Plutot thunderbird 2 + lightning + sunbird + connecteur sundird/obm en gpl (la release est pour bientot) ;-)
[ Répondre ]
Re: infos
Travaillant chez Aliasource, je vais faire un bout de réponse :
- le connecteur thunderbird sera très probablement (99% sur) en libre (GPL/MPL). De toute façon avec du xul et du js difficile de cacher les sources.
- le connecteur outlook sera (très probablement) prorio.
Ainsi l'utilisateur décidant de migrer sous thunderbird peut avoir une solution 100% libre. Il n'y a pas de release disponible actuellement du connecteur thunderbird. Il est fonctionnel mais utilise thunderbird 2.0 (releasé il y a peu) et les versions cvs de lightning/sunbird.
Concernant évolution, le développement des connecteurs a débuté chez nous par la mise en place d'un connecteur évo et du "serveur obm" (un web service). Nous attendions une annonce de novell sur la version win32 de evolution. Cette annonce n'est jamais venu et novell ne supporte pas officiellement la version win32. Nos clients ayant des postes utilisateurs linux étant rares, on ne pouvait pas se permettre de financer la r&d d'un connecteur qui ne serait utilisé que par quelques personnes en interne chez nous et nos 2/3 clients les plus geeks. Des traces de nos développements sur evo trainent sur le net http://lists.ximian.com/pipermail/evolution-hackers/2004-Oct(...) par exemple.
Pour ta première question sur la messagerie, il s'agit d'une chaine classique postfix, cyrus.
[ Répondre ]
Pour les curieux de la technique
Ca tourne sur du tomcat 5.x, avec du struts, du lucene, des templates tiles, du jfreechart, et bien sur xerces. Le tout est herbergé sur un cluster apache/tomcat avec une BD postgresql.
[ Répondre ]
Re: réalisé par une société spécialisée dans le libre
Yep j'ai participé au dev de ce portail et c'était une super expérience. L'équipe de lyon2 était très sympa et nous avons pu faire du bon boulot. Très bonne idée de passer la news sur linuxfr; moi qui pensait que ça n'interresserait personne :-)
Sinon si un modéro pouvait rajout un lien vers http://www.aliacom.fr/(...) (on a quand même fait la partie visible du taf).
[ Répondre ]
Comment ça marche ?
La dernière fois que j'ai eu des problèmes de jeux de caractère, je me suis posé la question "Est il possible de déterminer de manière fiable l'encoding des caractères dans un fichier texte", et la réponse que j'ai trouvé c'est "tu peux seulement savoir si c'est de l'unicode ou pas, pour le reste c'est très pifométrique et doit se baser sur des stats/dictionnaires/poudre verte.".
Un autre signe qui me fait penser que ça ne peut pas marcher c'est que la pluspart des api sérieuse devant traiter du texte exigent de connaître par avance l'encoding du texte (sous peine de retomber par défaut à l'encoding du système) : je pense à XML (encoding UTF-8 par défaut si non précisé), je pense à java pour lequel toutes les méthodes contruisant des String à partir de byte[] demandent un encoding (celles qui ne demandent pas l'encoding sont deprecated), je pense à la glib, etc.
Je m'interresse à la question car la dans le cadre d'un projet, une application web recevait des fichiers zip et devait les décompresser. Et la specification zip datant de l'époque "tout ascii", le champ des zip contenant le nom des fichiers est du type "tableau de char". L'encoding n'est précisé nulle part. Les utilisateurs de base étant fans des accents et autre ponctuation dans les noms de fichiers, j'ai découvert que je n'arrivait pas à décompresser un zip de manière fiable (restitution correcte des noms de fichiers).
D'ou ma question, paske la reconnaissance d'encodage me semble être un but innacessible, sur lequel pas mal de gens se sont cassés les dents ou on renoncés.
[ Répondre ]
Re: Workflows
Nous on utilise OSWorkflow pour faire ça.
[ Répondre ]
Re: PS
> - pour garder le meme processus utilisateur au fil des connexions
Pas utile. Java utilise des threads qui partagent tous le même espace mémoire.
> - sans pour autant saturer le serveur en memoire alloue
La mémoire est partagée donc chaque thread ne consomme que la "stack" allouée par le noyau (4Ko je crois) + l'espace utilisé pour le TLS (thread local storage) (Voir aussi la classe ThreadLocal en java). En gros sur du noyau 2.6 c'est pas un pb. Sur du 2.4 sans NPTL c'est un peu moins drôle, mais on parle de java, pas de linux.
> - et ou processus ou thread systeme.
Voir les annonces d'Ingo Molnar quand NPTL a été mergé dans le noyau (100000 threads avec une latence très faible sur PIV monoproc). C'est sur qu'a une époque reculée (2.4 sans NTPL), à partir de 300 process le noyau linux ne bougait plus. Maintenant no-souci.
En plus en java la bonne pratique est plutot de mettre le moins de choses possible dans la session et de consacrer ta ram a des caches LRU globaux pour éviter les requêtes en BD. En gros tu ne met quasiment rien dans la session et tu caches tout ce qui vient de la BD au niveau du serveur d'appli.
[ Répondre ]
Re: Marrant, ça...
Non, mon exemple n'est pas si mauvais que ça : pour ajouter ou enlever un élément du panier, ca va donner un insert ou un delete dans la bd. Et toute base qui se respecte écrit les modifications sur le disque de manière synchrone dans le log des transactions (et laisse trainer le tuple dans le cache en ram dans le cas d'un insert). Sans compter le transfert des données par le réseau vers la BD...
[ Répondre ]
Cette page a été générée par Templeet en 0.0866s (dont 0.0081 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Re: OBM-* & Calendar
C'est vrai, il existe une brique non-libre, pour nos clients qui veulent rester dans le monde proprio sur le poste client.
Mais outlook + connecteur n'est qu'une étape de transition vers thunderbird + lightning + connecteur ;-)
[ Répondre ]