Re: Répétition d'événement

[Ploc <pub2016 AT acampado.net>]

Hello,

Je ne sais pas si c'est un chantier "énorme", mais il est clair que 
c'est plus proche d'une ré-écriture (au moins partielle) que d'un patch.

C'est donc un chantier en soi qui représenterait un vraie rupture par 
rapport aux agendas actuels.

On aurait un front développé en php/js/ruby/python/ce-que-vous-voulez, 
et un back qui serait un serveur caldav (pour les événements) ou carddav 
(pour les contacts).

Selon moi, on essaie de sa passer d'une base de données SQL (sinon ça 
ferait 2 backends : le serveur caldav/carddav et la base de données, 
trop compliqué). Mais il faudrait que j'étudie mieux les données qui 
sont actuellement stockées en base.

Mais le serveur caldav/carddav pourrait quand même stocker pas mal de 
trucs :

- caldav : tous les événements, avec potentiellement toutes les 
métadonnées
- carddav : tous les contacts (modérateur, soumetteurs, groupes 
locaux...), avec potentiellement toutes les métadonnées

Il faut voir si la couverture fonctionnelle des protocoles caldav et 
carddav recouvrent l'ensemble des données actuellement stockées en base 
de données...

Après, on pourrait aussi imaginer une API REST, mais alors ça signifie 
abandonner les protocoles caldav et carddav et tous ce qu'ils peuvent 
nous apporter...

Ploc


Le 2016-09-16 13:41, echarp a écrit :
> Bonjour
>
> Et bien, faire un frontal web pour des serveurs de gestion de 
> calendrier
> n'est pas une mauvaise idée, mais cela me semble être un chantier
> énorme.
>
> Presque une réécriture.
>
> Sais tu si on peut tout stocker dans un serveur comme radicale, ou 
> alors
> faudrait il jongler entre une base de données SQL et le serveur
> d'agenda? Sans oublier un éventuel serveur de contacts.
>
> Cordialement
> --
> Emmanuel Charpentier - http://acoeuro.com - 06 62 80 30 56
>
> On Thu, Sep 15, 2016 at 11:36:07PM +0200, Ploc wrote:
> > Bonsoir à tous,
> >
> > Le 15/09/2016 à 21:10, echarp a écrit :
> > >
> > > Le problème finalement ce n'est pas fondamentalement le stockage ou la
> > > gestion des règles, c'est plutôt l'IHM et la manière de proposer tout
> > > cela aux utilisateurs.
> >
> > Ce qui n'est pas fondamental dans ta vision des choses était justement
> > le coeur de ma proposition : séparer le backend de stockage des 
> > données,
> > du frontend de présentation.
> >
> > Ca permet d'avoir plusieurs frontend pour un seul backend, ça permet
> > d'avoir une interface claire entre la backend et le frontend (caldav 
> > et
> > cardav).
> >
> > C'est vrai que ça ne résoud par le problème initial qui est de savoir
> > comment faire une ihm simple pour gérer les cas complexes.
> >
> > Mais mon propos était donc de parler de l'architecture logiciel des
> > projets d'agenda libre, pas d'ihm...
> >
> > Après, si ma proposition ne recueille pas d'écho, restons-en là sur 
> > cet
> > aspect des choses et concentrons nous sur le sujet de la récurrence et
> > de son utilisabilité...