Implmentation des fonctionnalits de calendrier.

  $Id: notes-icalendar.txt 834 2004-01-17 17:59:13Z fguillaume $

  Les difficults principales sont:

  - l'implmentation des vnements rcurrents,

  - les optimisations et caches pour avoir un fonctionnement rapide.

vnements rcurrents

  Il est IMPRATIF de lire la spec iCalendar (rfc 2445)
  (http://www.imc.org/ietf-calendar/index.html) pour comprendre
  l'ampleur des fonctionnalits possibles, et les choix techniques faits
  dans la spec afin d'avoir un modle fonctionnel commun, pour pouvoir
  interoprer avec d'autres calendriers, et aussi simplement pour tirer
  partie de l'exprience de ceux qui ont crit la spec.

  Par ailleurs le meilleur programme implmentant iCalendar est Apple
  iCal, et il est souhaitable de jouer avec pour comprendre comment
  fonctionnent les vnements rcurrents.

  Enfin il est important de noter que la principale difficult
  d'implmentation des vnements rcurrents vient du fait qu'on peut
  autoriser une instance d'une rcurrence  tre change (dplace en
  date/time, ou bien change dans un ou plusieurs de ses champs). Ces
  instances sont appeles instances "dtaches".

  L'implmentation des vnements rcurrents fonctionne ainsi:

  - un vnement a un UID, qui identifie  la fois l'vnement
    dfinissant la rcurrence et toutes les rcurrences de cet
    vnement (appel le recurrence set),

  - la rgle de rcurrence (RRULE) (spec 4.8.5.4) dfinit quelles sont
    toutes les rcurrences, et la date d'arrt ventuel. Il faudra
    commencer par implmenter des rgles simples tout en se gardant des
    possibilits d'volution,

  - dans la spec il y a aussi une EXRULE (spec 4.8.5.2) qui spcifie un
    rgle d'exceptions pour les rcurrence, mais on ne l'implmentera
    pas, de mme on n'implmentera pas les RRULE multiples,

  - une instance particulire d'une rcurrence est identifie par sa
    RECURRENCE-ID (spec 4.8.4.4), qui est la date de dbut de
    l'vnement (date+time si l'vnement n'est pas all-day),

  - si une instance d'un rcurrence est dtache (change d'heure par
    exemple), elle reste identifi par sa RECURRENCE-ID d'origine, en
    revanche sa date de dbut change (spec 4.8.4.4),

  - un vnement rcurrent possde des RDATE et des EXDATE. Les RDATE
    sont les dates supplmentaires auxquelles un vnement rcurrent est
    rajout (cette notion ne nous sert pas a priori) (spec 4.8.5.3). Les
    EXDATE sont les dates o un vnement rcurrent ne doit pas avoir
    lieu (spec 4.8.5.1),

  - quand une instance d'une rcurrence est supprime, sa RECURRENCE-ID
    est rajoute au EXDATE de l'vnement de base,

  - dplacement d'une instance: si l'utilisateur demande le dplacement
    d'une instance d'un vnement rcurrent, il faut lui demander si il
    veut dire:

    - dplacer cette occurence seulement, auquel cas on fait un
      dtachement de l'instance,

    - dplacer cette instance et toutes les suivantes, auquel cas il
      faut faire un split de l'vnement rcurrent en deux vnements
      rcurrents, le premier s'arrtant avant l'instance choisie, et le
      deuxime recommenant  la nouvelle version de l'instance choisie,

  - modification d'une instance: si l'on demande la modification d'un
    champ d'une instance d'un vnement rcurrent, il faut de mme
    demander  l'utilisateur si il veut dire:

    - modifier cette occurence seulement, auquel cas on fait un
      dtachement de l'instance,

    - modifier cette instance et toutes les suivantes, auquel cas on
      splitte,

Notes diverses par rapport  iCalendar

  - on ne traitera pas les timezones, et on stockera toutes les dates en
    UTC,

  - le RFC n'est pas explicite sur beaucoup de points. Apple iCal reste
    la meilleure rfrence et implmente souvent le consensus des
    mailing-lists sur iCalendar.

Optimisations et caches

  Il est hors de question d'instancier une rcurrence d'vnement 
  chaque fois qu'une rcurrence doit tre visualise, pour des problmes
  de performance et de taille de stockage. Les vnements ne sont donc
  pas des objets de premire classe qu'on visualise directement.
  L'object Calendar doit avoir une mthode getEvent(...) qui retourne un
  objet vnement non persistent, qui lui-mme a des mthodes
  d'affichage.

  Un algorithme de base  implmenter est celui qui calcule le
  recurrence set en fonction de RRULE et de EXDATE.

  Il faut pouvoir retrouver rapidement les vnements instancis
  dans une plage de temps donne (probablement utiliser un Catalog local
  au calendrier pour cela, avec au moins des index pour UID, DTSTART,
  DTEND, RECURRENCE-ID).

  Le Calendar doit avoir, pour chaque UID, un cache sur certaines
  priodes (le mois me semble une bonne granularit de base) du
  recurrence set valable pour cette priode (avec inclusion des
  vnements dtachs). Le cache doit tre invalid ds qu'un vnement
  avec cette UID voit une des ses dates modifies.

  Il faudra implmenter des algorithmes efficace d'intersection de
  priodes de temps multiples.
