De rien, ravis d'avoir fait avancé le débat (et le PIB de ton pays). Et désolé d'avoir été/d'être quelques peu abrasif...
J'ai déja lu la RFC concernant vCalendar et je ai déja écris un sérialiseur (ok c'est la partie la plus simple), je continue de penser que cela est loin d'être complexe et je penses que sortir un moteur de grammaire risque d'être contre-productif, enfin bon libre à toi d'expérimenter et de nous faire part de tes nouvelles expériences.
Je persiste à penser que la complexité se retrouve dans l'organisation logique des données, par exemple (pour vcal) comment représentes-tu les timezones ? Comment gèrer les différentes addresse et leur rôle (je pense que c'est une notion que la RFC utilise), les liste d'adresses, les groupes, etc.. Bref, vCard c'est un peu plus que un format, l'interropérabilité se joue vraiment dans la couche plus haut. Et je ne suis pas sur que toutes les recommandation de la RFC suffisent à avoir une interopérabilité maximale. Maintenant là où c'est paradoxal, c'est qu'avoir une bibliothèque "haut-niveau" (qui au passage adhère à toutes les recommandation de la RFC mais celon moi c'est anecdotique cf. phrase précédente) va t'imposer des choix d'organisation logique de tes données; ce qui risque de enter en conflit avec ta base de code actuelle ou future (mais bon disons que c'est accessoire comme difficulté) et en même temps limiter ton interropérabilité avec les autres solutions... Oui c'est paradoxal. De ce point de vue, il me semble qu'avoir une bibliothèque la plus simple possible est un avantage (reste à toi de combiner les briques ensembles). Objectivement, ce n'est que mon avis, je ne prétends pas parler en connaissance de cause et je conçois que tu puisses avoir un avis contraire.
Aussi, en ce qui concerne la couche "transport" c'est sans doutes dommage pour toi qu'il n'y aie rien de tout-en-un, mais, je me répète, et comme pour le problème d'organisation logique "high-level", je consière que cela est plustôt une bonne chose. Un jour peut-être vas-tu devoir supporter imap, où le protocol X ? Conceptuellement, cela me semble plus propre de découpler ces partie et plus à même de s'adapter aux contraintes futures...
La question de l'usage que tu comptes en faire reste. I.e. avec quoi tu veux interragir et de quelle façon. Cela nous permettra de t'aider à trouver une solution clef-en-main, si elle existe. (Aussi cela permet d'assouvir ma curiosité). Bon on sait déja que ce n'est pas une GUI Qt :P
[^] # Re: Pour faire avancer le schmilblick...
Posté par benja . En réponse au message Cherche librairie CardDAV et/ou VCard 4 (pas 3 ni 2.1), open source et en C ou C++. Évalué à 1. Dernière modification le 29 octobre 2015 à 15:50.
De rien, ravis d'avoir fait avancé le débat (et le PIB de ton pays). Et désolé d'avoir été/d'être quelques peu abrasif...
J'ai déja lu la RFC concernant vCalendar et je ai déja écris un sérialiseur (ok c'est la partie la plus simple), je continue de penser que cela est loin d'être complexe et je penses que sortir un moteur de grammaire risque d'être contre-productif, enfin bon libre à toi d'expérimenter et de nous faire part de tes nouvelles expériences.
Je persiste à penser que la complexité se retrouve dans l'organisation logique des données, par exemple (pour vcal) comment représentes-tu les timezones ? Comment gèrer les différentes addresse et leur rôle (je pense que c'est une notion que la RFC utilise), les liste d'adresses, les groupes, etc.. Bref, vCard c'est un peu plus que un format, l'interropérabilité se joue vraiment dans la couche plus haut. Et je ne suis pas sur que toutes les recommandation de la RFC suffisent à avoir une interopérabilité maximale. Maintenant là où c'est paradoxal, c'est qu'avoir une bibliothèque "haut-niveau" (qui au passage adhère à toutes les recommandation de la RFC mais celon moi c'est anecdotique cf. phrase précédente) va t'imposer des choix d'organisation logique de tes données; ce qui risque de enter en conflit avec ta base de code actuelle ou future (mais bon disons que c'est accessoire comme difficulté) et en même temps limiter ton interropérabilité avec les autres solutions... Oui c'est paradoxal. De ce point de vue, il me semble qu'avoir une bibliothèque la plus simple possible est un avantage (reste à toi de combiner les briques ensembles). Objectivement, ce n'est que mon avis, je ne prétends pas parler en connaissance de cause et je conçois que tu puisses avoir un avis contraire.
Aussi, en ce qui concerne la couche "transport" c'est sans doutes dommage pour toi qu'il n'y aie rien de tout-en-un, mais, je me répète, et comme pour le problème d'organisation logique "high-level", je consière que cela est plustôt une bonne chose. Un jour peut-être vas-tu devoir supporter imap, où le protocol X ? Conceptuellement, cela me semble plus propre de découpler ces partie et plus à même de s'adapter aux contraintes futures...
La question de l'usage que tu comptes en faire reste. I.e. avec quoi tu veux interragir et de quelle façon. Cela nous permettra de t'aider à trouver une solution clef-en-main, si elle existe. (Aussi cela permet d'assouvir ma curiosité). Bon on sait déja que ce n'est pas une GUI Qt :P
Au plaisir :)