Salut à tous et à toutes,
Je suis à la recherche d'une librairie C ou C++ open source (MIT, BSD ou GPL) qui gère soit le protocole CardDAV, soit les VCards au format 4.0, soit les deux.
Tout ce que j'ai pu trouver jusqu'à présent se limite à ça:
https://github.com/drppublic/libVCard4
Merci d'avance.
# Pour faire avancer le schmilblick...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 4.
La majorité d'entre nous ne connait pas… mais quel est le problème avec "ça" ?
Autre question importante : tu cherches une lib client ou serveur ?
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Pour faire avancer le schmilblick...
Posté par Sylvain Berfini (site web personnel) . Évalué à 2.
La lib est pas maintenue, elle ne gère pas l'export et pas le protocole CardDAV.
En plus la lib ne compile pas sur ma machine (bien que ça puisse se réparer).
Je cherche une lib cliente.
[^] # Re: Pour faire avancer le schmilblick...
Posté par benja . Évalué à 0. Dernière modification le 28 octobre 2015 à 18:03.
Peut-être que l'auteur n'éprouve pas le besoin de l'améliorer ?
Faux.
https://github.com/drppublic/libVCard4/blob/master/VCard4.cpp#L127
Et ? Ah mon avis il est plus sain pour cette librairie de se limiter à la partie vcard. Trouves toi une autre librairie pour faire la partie webdav/carddav qui s'intègre bien avec le reste de ton programme.
OK. J'allais te dire te regarder du côté du code de kdepim pour d'autre resources, mais bon cela serait une perte de mon temps vu les efforts que tu sembles prêt à mobiliser… :)
[^] # Re: Pour faire avancer le schmilblick...
Posté par Sylvain Berfini (site web personnel) . Évalué à 2.
Ok, j'avais pas fait gaffe.
C'est un peu le but de mon post aussi, j'en ai pas trouvé non plus.
La lib vcard de KDE dépend de QtCore, et j'ai pas envie de ramener cette énorme dépendance juste pour ça…
[^] # Re: Pour faire avancer le schmilblick...
Posté par benja . Évalué à 0.
http://curl.haxx.se/libcurl/competitors.html
boost_asio
http://stackoverflow.com/search?q=[c++]+http+library ??
Je n'ai pas de réelle suggestion à te faire n'ayant jamais eu de besoin similaire en C++.
[^] # Re: Pour faire avancer le schmilblick...
Posté par benja . Évalué à 2.
J'ai l'impression qu'il serait bon que j'explique ce raisonnement. Lire/écrire du vcard, cela se fait en quelques classes (cf. la bibliothèque mentionnée). Par contre, un "client" CardDAV, qui je le rappelle n'est ni plus ni moins qu'un client HTTP supportant les verbes WedDAV et qui utilise vcard comme format déchange, ben tu peux le faire, à priori, avec n'"importe quelle" bibliothèque HTTP suffisemment aboutie. Il va de soit que la complexité d'une bibliothèque HTTP est bien plus grande.
Donc, il n'y a aucune raison que les deux soient couplées, au contraire tu n'aurais que des inconvénients d'avoir deux implémentation incomplète (ah tiens je voudrais de l'http-pipelining maintenant, et puis de l'http-auth, et puis intégrer dans ma boucle d'évènement pour ne pas avoir de freeze de ma gui, etc. at infinitum).
Permettez moi (je m'adresse aussi aux autres lecteurs/moinsseurs) de trouver cela curieux de devoir expliquer cela à un développeur de C++, cela me semble évident. Tout comme il me semble évident que parser du vCard est "trivial", au point qu'utiliser une bibliothèque déja faite entraine des contraintes: cela nécessite une transformation d'une représentation interne des données vers la représentation qu'utilise cette bibliothèque.
J'avoue que j'ai l'impression que la personne postrice est incompétente, peut-être devrais-je plustôt supposer qu'est-elle novice (le "vCard >= v4.0" ressemble à un /requirement/ de type professionnel…). Ceci mis de côté, j'aimerais pouvoir lire vos arguments afin de savoir en quoi je me trompes et de ce fait apprendre moi aussi de vos opinions. Pour la même raison j'aimerais savoir ce que Viish essaye de faire. Enfin bon je ne vais pas mettre l'espoir d'avoir un retour trop haut, mon ratio énergie/(satisfaction d'aider + satisfaction d'apprendre) est déja passé au travers du plafond :P
[^] # Re: Pour faire avancer le schmilblick...
Posté par Sylvain Berfini (site web personnel) . Évalué à 1.
Oui, mais une librairie CardDAV en plus de gérer l'aspect HTTP, gère aussi le protocole, dont notamment la découverte des addressbooks, etc…
Bien que lorsqu'on regarde un fichier VCard le format à l'air simple, parser une VCard correctement (c'est à dire en respectant la RFC) n'a rien de trivial.
Je ne suis ni incompétent, ni novice. Je suis juste à la recherche d'une ou deux librairie(s) gérant le VCard 4 (oui c'est un nécessaire professionnel) et le protocole CardDAV.
Comme je suis arrivé à la conclusion par moi même qu'il n'existait aucun ensemble de librairies ne répondant à mon problème, et disposant déjà d'une stack HTTP et d'un parseur sachant lire une grammaire ABNF, je vais écrire mes propres librairies, ce que je voulais éviter en premier lieu (pourquoi créer une librairie si une équivalent existe déjà ?).
Merci quand même.
[^] # Re: Pour faire avancer le schmilblick...
Posté par benja . É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 :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.