=?ISO-8859-1?Q?Re:_RE_:_[Tsp-devel]_XML, _Databa?= se et Browse : proposition à TSP

[Eric Noulard]

> Soyons clairs,

Il était temps :))
Mais après ces 2/3 messages je ne comprends pas exactement ce que tu propose.

> si un provider TSP mets à disposition une interface BD (serveur SQL,
fichier ou
> autres choses plus simples), cette interface ne fournira que de la meta-data
> (structuration par le relationnel, user-name, attributs,
provider-sid, ....). Le contenu
> des paramètres devra suivre le canal standard de TSP via
l'identifiant provider-sid.

Je note juste que c'est déjà "un peu" le cas la requête

TSP_Request_ExtendedInformation

le provider fourni (si il a l'info) une liste d'information étendue
sur les PGI fournis en paramètre.

1 information étendue est une paire "clef" "valeur" ou la clef
est une chaine et la valeur est également une chaine de caractère.

C'est bien une liste "A PLAT" de meta-donnée concernant le symbole
indiqué par son PGI.

Les valeurs évolutives de ce symboles sont toujours reçues
via le canal synchrone (ou un éventuel read asynchrone).

Je vois aussi des liens avec la Request Filtered Informations
qui a pour but d'éviter de ramener LA TOTALITE de la liste des
symboles.

Est-ce que ta solution de "dépliage de folder" côté consumer
générerait des request filtered pour "découvrir" la suite d'un folder?

> J'espère avoir été (un peu plus) clair !

Je demande encore quelques précisions:

- Ta proposition concerne-t-elle côté le provider ou
  bien est-ce UNIQUEMENT à chaque consumer de 'charger'
  ces infos XML pour faire du "rendering" des infos "A PLAT"
  du provider?

- Si ça ne concerne que le consumer qu'est-ce que ta solution
  apporte de plus qu'un "bête" fichier de conf XML?
  (je taquine mais c'est pour faire avancer le schmilblick)

- Si ça nécessite de rajouter un échange consumer/provider
 quel serait le prototype de la nouvelle requête?



>         Obscur-ô-Bob

           CL-Erk-Osbcur.

--
Erk