RE: [sdx-users] qid multi-session

[Emmanuel Bégué]

> -----Message d'origine-----
> De : address@hidden
> De la part de Frédéric Glorieux
> Objet : Re: [sdx-users] qid multi-session
>
>       SDX est un environnement de diffusion, vous voulez en faire
> un système de production ?

Qu'entendez-vous par "production"? Production de documents xml?
Mon autre message sur l'édition de documents xml peut le laisser
penser (mais en fait comme vous dites ce serait plutôt pour des
modifications très ponctuelles), mais ici pour les jeux de
résultat multi-sessions on reste bien dans la diffusion?


> Vous nous ferez bénéficier de votre expérience et de vos sources ?

En la matière je n'ai pour l'instant pas grand chose à contribuer,
mais sinon oui, certainement.

Justement, ne serait-il pas intéressant de disposer d'un endroit
où les utilisateurs SDX pourraient échanger du code -- du code xsl
en particulier (en plus de cette liste)?

J'ai par exemple écrit deux petites fonctions xsl qui sont assez
génériques, l'une pour afficher l'historique de la recherche, et
l'autre pour highlighter avec une couleur différente par mot (à la
Google) et je ne sais pas comment les "contribuer au projet" (les
poster à la liste est un peu incongru?); d'autres sont certainement
dans le même cas que moi (et même pour ce qui n'est pas générique,
les idées de chacun sont toujours "inspirantes") -- sans compter que
ça permet d'éviter de réinventer la roue tous les matins ;-)


>       Actuellement, les utilisateurs SDX sont des documents dans une base
> spécifique. Il y quelques champs d'identification et un mot de passe. Le
> modèle du dossier utilisateur pourrait être intéressant.
>
>       Mais pour l'utilisateur "anonyme", voulez-vous un seul
> dossier, ou bien créer quelque chose à chaque session ouverte
> en servlet ? Pour un site à grand traffic, ceserait inquiétant.

L'utilisateur anonyme n'a pas de dossier, ça ne me semble pas un
problème: s'il veut un dossier il se crée.


>       L'objet Results pourrait peut-être se résumer à une liste
> d'identifiants de cette sorte idDoc-idBase-idApp-uriRMI. On peut aussi
> considérer que pour votre application (et le client), ce n'est qu'une
> liste d'URI.

En fait les identifiants des documents devraient suffire (et c'est
plus simple et plus sûr que de stocker littéralement l'uri?)


>       Si votre but est la valeur ajoutée à un site grand public, on peut
> aussi penser aux cookies (y inscrire les URIs de docs qui vous
> intéressent), ce qui allège votre serveur.

Oui, je ne sais pas: l'intérêt du stockage sur le serveur c'est que
l'utilisateur retrouve son dossier intact quelle que soit la machine
avec laquelle il se connecte...

Cdt,
EB