sdx-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: RE : [sdx-users] base XML native (Xindice,Exist) et SDX


From: Emmanuel Bégué
Subject: RE: RE : [sdx-users] base XML native (Xindice,Exist) et SDX
Date: Tue, 6 May 2003 23:58:50 +0200

Ok je suis convaincu qu'il faut regarder cette solution en détail;
quel est le meilleur doc pour commencer simplement avec Cocoon?

Merci de ces conseils,
Cdt,
EB

> -----Message d'origine-----
> De : address@hidden
> [mailto:address@hidden la part
> de Pierrick Brihaye
> Envoyé : mardi 6 mai 2003 19:52
> À : address@hidden
> Objet : Re: RE : [sdx-users] base XML native (Xindice,Exist) et SDX
>
>
> Re,
>
> > Pas compris? qu'est-ce qui est déjà dans le lookup?
>
> Entre autres choses, l'id de ton document et l'entrepôt dans lequel il se
> trouve. Comme un jeu d'index peut, naturellement, concerner plusieurs
> entrepôts, c'est bien pratique... Si j'ai bien compris ton cas,
> tu stocke un
> "moyen" d'accès au document, ce qui revient bien au repository du lookup,
> non ? En moins puissant d'ailleurs...
>
> > Oui et non; ce n'est pas l'objet de SDX de gérer des problématiques
> > complexes de droits d'accès aux documents en fonction d'abonnements,
> > de gestion de la cinématique d'abonnement, de récupération de droits
> > depuis des systèmes externes, etc.?
>
> Pourquoi pas ? Tout cela peut donner lieu à des documents, non ? Donc SDX
> devrait savoir les gérer ;-) La userDocumentBase de SDX est d'ailleurs un
> excellent exemple de ce genre de problématique IMHO.
>
> > Oui, un mécanisme à la sitemap est probablement ce qu'il faudrait; si je
> > théorise le cas dans lequel je me trouve, en fait on a un stockage des
> > documents qui est toujours organisé selon une structure identique, mais
> > qui sépare physiquement les documents sur des serveurs distincts en
> fonction
> > de critères divers (nature du document, entité qui l'a produit, etc.).
>
> Donc, c'est bien d'une sitemap dont tu as besoin :-). Chaque serveur
> exposerait sa sitemap à SDX et l'URL
http://server/documents_pour_SDX/xxx te
dirigerait vers la ressource ad hoc. Plus fort encore, on peut avoir une
"sur-sitemap" qui, avec http://anyserver/documents_pourSDX/xxx te renverrait
vers http://server1/documents_pour_SDX/xxx ou
http://server2/documents-pour_SDX/xxx...

Au fait : tu sais que tu peux utiliser Cocoon *sans* SDX ? :-)))

> Pour utiliser les entrepôts url en profitant de la souplesse de base_url
> il faudrait nécessairement reproduire la structure physique des serveurs
> dans les entrepôts SDX, ce qui est inutilement compliqué (et multiplie le
> nombre de fichiers ouverts); si on veut n'utiliser qu'un seul entrepôt
> url il faut stocker l'url absolue (et donc réindexer si le serveur change
> de nom).

Honnêtement, étudie la solution Cocoon ; je crois vraiment que c'est ce dont
tu as besoin. C'est tout de même plus facile de gérer une fois une
arborescence infernale et ensuite des URL simplissimes du type
http://anyserver/documents_pourSDX/xxx que N fois une arborescence
infernale, non ? Je te propose donc, pour faire encore plus fort que ce qui
est indiqué ci-dessus (car tu n'auras pas à toucher aux autres serveurs), de
créer ta propre appli Cocoon (SDXRedirector) qui disposerait d'une sitemap à
même de dispatcher vers les arborescence ad hoc.

Une fois qu'elle tourne, on l'intègre dans le contexte /sdx :-)

A+

p.b.





_______________________________________________
sdx-users mailing list
address@hidden
http://mail.nongnu.org/mailman/listinfo/sdx-users





reply via email to

[Prev in Thread] Current Thread [Next in Thread]