Le soucis d'éviter autant que possible les agenda-xx en particulier pour différencier plusieurs elements dont les parents sont différents est légitime.
Ouf... 
Le stockage complet est une réponse technique qui verse dans la facilité mais qui est insatisfaisante.
Nous n'avons toujours eu l'habitude de privilégier la qualité des solutions sur leur facilité, et on ne va pas changer de façon de faire maintenant.
Donc, oui il faut améliorer les url arbos pour résoudre les petits défauts constatés, mais non il ne faut pas stocker les url complètes.
C'est une bonne approche dans l'absolu, certes, mais j'ai l'impression qu'à moins de trouver une solution relativement simple, tu ne sois ici trop puriste.
Le seul soucis -- très relatif -- que j'imagine c'est de provoquer le recalcul des URL d'une branche descendante (et non remontante comme les branches des boucles SPIP) en cas de changement d'une rubrique au niveau de son titre ou de sa rubrique mère.
C'est à mon sens quelque chose qui n'arrive pas très souvent, donc largement acceptable même pour un renommage de secteur sur un gros site, où l'incohérence entre nouvelle arborescence réelle et arborescence vue dans les URL disparaîtra au fur et à mesure des recalculs de cache, sans empêcher la navigation grâce aux redirections 301 automatiques.
Bien sûr, s'il y a des contre exemples à ce que j'avance, je suis tout ouï.
La solution réside amha dans le stockage de l'id du parent en plus de l'url propre de l'objet, et d'avoir une clé primaire composée sur (url,id_parent)
- dans les cas des url non arbo, les id_parent restent à zero -> on retrouve le fonctionnement d'origine
- dans le cas des url arbo, on sera capable de distinguer deux objets avec la meme url mais de parents differents
Mais, déjà, par cette implémentation, on créé des problèmes connexes potentiels lors des déplacements d'objet, chose qu'on a voulu éviter dans notre implémentation.
Cette proposition me semble inutilement compliquée, dans son principe et donc probablement dans son implémentation, par rapport à l'enjeu.
Le cas de RastaPopoulos est un peu plus vicieux, car il ajoute dans l'url propre d'un objet des segments en formatant la date sour la forme 2008/08/truc
Les urls popres arborescentes ont été pensées comme représentatives de l'arborescence des objets, chacun représentés par son url propre. En produisant une url d'objet comportant des / supplémentaires, cela casse le lien entre arborescence de l'url et arborescence des objets Spip, et ne marche effectivement pas.
Ce qui ne serait pas le cas, une fois de plus, avec des URL stockées complètes.
Il est possible de corriger l'analyseur d'url chargé de retrouver l'objet à partir de l'url et de ses segments, mais je ne suis pas sûr que cela soit pertinent car susceptible de provoquer d'autres bugs, du genre collision d'url d'objet à des profondeurs différentes.
Dangereux, effectivement.
Je pense que la gestion des url arbo ne sera pas modifiée pour la sortie de la 2.0
Il n'y a à priori pas de gros risques à la modifier, puisqu'elle n'a jamais été dans une version stable de SPIP, mais c'est sans doute plus un problème de délai, pour ne pas retarder la version stable.
mais elle pourra évoluer pour être améliorée par la suite.
Cool !
-Nicolas
