Fil, est-ce que tu pourrais expliquer le but pratique des documents
distants?
En pratique, je fais un portail (disons, par exemple, rezo.net) qui
référence un tas de saloperies sur Internet ; des articles, des PDF, des
mp3, des jeux vidéos complets, des films (le mariage de Tonton Nono en vidéo
fullscreen, la dernière release des 4 DVD de la Debian, etc.). Pour l'heure
je ne peux pas mettre ces documents sous forme de "documents" SPIP ; avec
les documents distants, je peux.
La difficulté, comme tu le soulignes, c'est que pour certains de ces
documents il est utile d'avoir une copie locale, tandis que pour d'autres il
vaut mieux éviter, citons par exemple :
- fichiers exécutables ou changeant à chaque hit
- fichiers de taille monstrueuse, que tu stockes chez free^H^H^Hailleurs
- documents non http [pas implémenté encore], du style bittorrent
- fichiers partagés entre plusieurs sites
Pour ce qui est des RSS que tu syndiques et qui contiennent des docs joints,
ton site peut être basé dessus (là tu vas vouloir ou non faire une copie
locale), ou pas (là, pas de copie locale).
Tu peux toi-même ajouter des docs joints "distants" dont certains appellent
une copie locale, d'autres non.
Donc, par défaut, il n'y a pas de copie locale obligatoire -- cependant
(hint) en fait il y en a déjà une de faite pour les vignettes, et c'est
précisément ça qu'il faut encore étendre (voir ci-dessous).
Parce qu'en l'état, c'est assez incompréhensible, et ça rend
la gestion des documents totalement incohérente.
Si tu n'as pas compris, tu ne peux pas prétendre que c'est incohérent 
-> D'abord, je vois que ça ne recopie le document sur le site.
Exact
C'est un simple lien vers une page externe.
Presque exact.
* Si le site distant sucre le document, on se retrouve avec de
l'erreur 404 dans le site.
* Si le site distant remplace le document, on se retrouve
carrément avec n'importe quoi sur son propre site. Sur un site
collaboratif ouvert aux contributions, ça ressemble à une trou de
sécurité niveau contenus: quelqu'un insère un «document» dans un
article proposé, on valide le truc, et ensuite l'auteur change son
document chez lui. Les admins sont plantés avec un contenu affiché sur
leur site qu'ils n'ont pas réellement validé.
Là c'est du pur troll ! Sinon on interdirait les liens hypertextes (mêmes
causes, mêmes conséquences), les sites référencés, etc. Le fait que
quelqu'un puisse indiquer <img src=http://monsite/xxxx.jpg> dans la page est
du même niveau de "trou de sécurité contenu" que les documents distants
(c'est-à-dire pas un trou).
Non, ce qui manque à SPIP, c'est un outil de gestion des liens morts ; c'est
dans la TODO depuis 3 ans, un jour quelqu'un va s'en occuper 
Mais en
l'occurrence ma proposition ne change rien de ce point de vue, ni mieux, ni
pire.
-> La gestion de documents à l'extérieur ajoute, de plus, le problème
des traitements internes de SPIP qui deviennent inopérants.
Ah, voilà qui devient intéressant.
* Si on veut développer les indexations de documents, alors il
faut à chaque fois prévoir qu'on travaille sur des fichiers externes.
* Côté portfolio, c'est la catastrophe absolue: impossible de
«retailler» un fichier externe.
Catastophe "absolue", disons que tu exagères un *tantinet*. D'une part, dans
mon message explicatif je dis que cette partie-là n'est pas encore figée ;
d'autre part, le système actuel récupère déjà une copie locale des fichiers
dans certaines conditions (images pas trop délirantes), pour faire une
vignette.
=> Donc, je voudrais que tu précises le but exact des documents
externes.
* Soit c'est pour référencer des documents de l'extérieur du site.
Auquel cas ça pose de nombreux problèmes, c'est plus dans la logique
des feeds RSS que des documents joints. Et il faut penser une ergonomie
adaptée, parce que tout appel vers l'extérieur signifie contrôle des
modifications, suivi des mises à jour, etc.; et c'est l'usine à gaz
assurée.
* Soit c'est une interface pour simplement installer des documents
sur son propre site. Je crois que Gallery fait ce genre de choses. Dans
ce cas, c'est sympa, mais alors il faut sans doute simplifier (pas
besoin du petit symbole d'attachement externe).
Pourquoi "soit/soit" ? Car en fait il s'agit des deux.
Tu as mis le doigt sur le point qu'il me restait à travailler ; j'ai pas
encore fini, mais ça vient : le dernier étage, donc, de ce système, c'est un
filtre |copie_locale -- qu'on pourra/devra installer en standard dans tes
fonctions malicieuses (reduire_image, indexer_document, etc). Ce filtre fera
ce qu'on imagine, à savoir
function copie_locale($url) {
1. calculer adresse locale du fichier
2. si le fichier n'existe pas, aller le chercher et le
sauvegarder
3. en cas d'erreur, renvoyer ''
4. sinon renvoyer l'url locale
}
A ce compte-là, tu peux imaginer référencer les derniers DVD de ta
collection de films familiaux par une #URL_DOCUMENT (distante, donc, pour
les films "distants" dont tu ne veux pas dans IMG/) ; les images que tu as
téléchargé façon "gallery" par un [(#URL_DOCUMENT|copie_locale)], et
certains fichiers, pourquoi pas, par un truc composé du style :
<a href=#URL_DOCUMENT>document</a> [- <a href=(#URL_DOCUMENT|copie_locale)>copie locale</a>]
Mais d'autres possibilités sont encore imaginables, notamment s'il s'agit de
transformer les documents distants, de les dater, de vérifier leur URL
toutes les semaines, etc. Toutes choses que tu perds si tu restes dans le
modèle "je copie localement et j'oublie l'URL de départ".
Il manquera encore, c'est sûr, quelques petites bidouilles, notamment dans
l'interface :
- pouvoir modifier l'URL distante
- pouvoir vider/mettre à jour la copie locale
- savoir, dans le portfolio, si les docs ont ou non une copie locale
fonctionnelle (le trombone pourrait alors changer de couleur de fond ou de
commentaire)
Une partie de ces fonctions ne sont pas spécifiques aux documents distants
(remplacer un document, par exemple) mais relèvent (comme je l'ai écrit, je
crois dans mon mail de présentation) plutôt d'une "galerie" des documents,
toujours dans la TODO.
En ce qui concerne le filtre copie_locale(), il n'est pas si trivial que ça
à implanter, à cause du charset distant, du nom qu'on veut donner au fichier
local, etc. Et il faut essayer de voir quels sont les usages possibles, y
compris ceux que je n'ai pas envisagés ; c'est aussi pour ça que j'attendais
des réactions de la liste (mais la tienne est la première).
-- Fil
