RE: RE : RE : [Tsp-devel] XML, Databa se et Br owse : proposition à TSP

[eric.noulard]

-----Original Message-----
From: address@hidden on behalf of PAGNOT, Robert
To: 'Transport Sample Protocol development list'
Subject: RE : RE : [Tsp-devel] XML, Databa se et Browse : proposition à TSP
 

Je suis désolé je dégomme les couleurs car je suis texte-only...
Mais je vais restreindre les questions/réponse pour que ça reste compréhensible.

> Bob said:
>Ma proposition rajoute la possibilité de structurer les paramètres, mais aussi 
>de rajouter ad-libitum des infos sur chaque objet "structure" lui-même. Je >ne 
>pense pas que les metadata publiées ainsi doivent se substituer au mécanisme 
>"Extended Information", mais plutôt d'insérer les données "Extended 
>>Information" à l'arbo XML. Avec les classes IHM XDBO, il devient trivial pour 
>un consumer d'afficher TOUTES les metadata, quelque soit leur source.

Donc je comprends mieux.
Tu propose de RAJOUTER un service offert par un provider TSP MAIS qui ne 
passerait PAS DU TOUT par le canal
de commande habituel mais une AUTRE interface de type 'base de donnée'.

>> Erk said
>>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.

> and Bob  answered:
>Non, car la Request_Filtered se base sur le NOM des symboles (en tout cas si 
>je me souviens bien ...).

En fait la request_filtered était (?est?) destiné à offrir un mécanisme 
GENERIQUE de filtrage des symboles

http://cvs.savannah.nongnu.org/viewcvs/tsp/src/core/rpc/tsp_rpc.x?root=tsp&view=markup
TSP_answer_sample_t TSP_REQUEST_FILTERED_INFORMATION(TSP_request_information_t 
req_info, int filter_kind, string filter_string<>) = 112;

Le filter_kind qui est un int/enum décris le 'genre' du filter (NO_FILTER, 
expression réguliere, simple match (strstr), requête SQL etc...)
Chaque provider est libre de supporter 0  ou plus de type de filtre suivant ses 
capacités.

La filter_string est une chaine (:)) qui décrite la REQUETE de FILTRAGE dans le 
verbiage du 'filter_kind' sélectionné.
Par exemple
  filter_kind   = TSP_FILTER_SIMPLE
  filter_string = "toto"

alors oui on chopppe "simplement" les symboles dont le nom contient "toto".

Mais on pourrait aussi faire:
  filter_kind   = SQL
  filter_string = "SELECT * FROM SYMBOLS WHERE NAME like "%dynamic%" and 
UNIT="s"

En tous les cas le consumer reçoit une liste de symboles contenu dans une
answer_sample. Une Liste plate donc, mais le consumer peut "générer" des folders
en indiquant qu'un "folder" correspond à une REQUEST_FILTERED_INFO spécifique.

(au fait la doc la doc d'API 
http://www.ts2p.org/tsp/API_doc/html/group__TSP__ConsumerLib.html#ga15 
 est dispo en ligne même si dans ce cas elle n'est visiblement pas à jour)

> Bob said:
> Or ici, il s'agit de FOLDERs qui contiennent (éventuellement) 
> d'autres FOLDERs et (éventuellement) une liste de symboles de ce FOLDER.
> On obtient à la fin une structure semblable à un FileSystem, ou chaque 
> symbole est un "fichier". 
> Chaque "fichier" contient les metadata, les infos d'accès (le PGI !),
> mais aussi (pourquoi pas), les "Extended Information".

Oui je vois assez bien l'intérêt de la structure filesystem.
Quoiqu'il en soit dans ce genre de "choix" de "classement" il ME parait
souhaitable que cet PRESENTATION hierarchique des choses ne soit
qu'une "VUE" du consumer.

> Bob said:
> Le provider propose des services type DataBase (pas nécessairement XML !) 
> : une vraie BD, des fichiers quelconques ... + 

     Pourquoi pas.
     C'est parce que tu considère que les méta-data 

> Bob said:
> un driver d'accès en Java (pour le client) pour découvrir 
> ces données selon le schema (au sens URI) qui va bien.

     C'est la que je pense au côté "multi-plateforme".
     Si le provider veut aider "suffisamment" les consumers
     il ne doit pas y avoir qu'un driver Java (mais aussi C, C#, Ruby, Python, 
etc...)
     Le but de la request_filtered_info est bien d'encapsuler dans le couple 
'(int/string)=(filter_kind/filter_string)'
     ce genre de "driver" mais pour TOUT les langages.
     Ensuite savoir QUEL moteur traite ce 'filter_kind' (BD SQL, BD XML etc...)
     est un choix 'provider specific'.

> Bob said:
> Côté consumer, il se connecte à la Database (via le driver Java), charge 
> (tout ou partie de) 
> l'arborescence des metadata des symboles organisés en FOLDERs, et les 
> affiche. 
> Tout ça, en moins de 10 lignes de code Java !

     Je vois l'intérêt mais c'est consumer-specific et java spécifique
à moins d'avoir des specs des formats/protocoles utilisés et les implem' idoine
dans chaque langage.

> Bob said:
> Le drag-&-drop est alors trivial pour construire la liste des symboles 
> que l'on veut voir (en synchrone ou asynchrone).

Ok pour ça oui.

> Bob said:
> L'INDEPENDANCE provider-consumers !
> Il n'y a plus rien à installer côté consumer, 
> plus besoin de montages NFS, et autres cochonneries !

Ok c'était aussi le but de la request_filtered_info.

> Bob said:
> Le modèle XDBO permet aussi de mélanger au sein d'une même arbo XML des 
> symboles provenant de différents providers, et de façon dynamique.

C'est très souhaitable comme propriété.
En revanche...

> Bob said:
> Ce qui est délicat à faire avec des fichiers de conf.

Je ne suis pas d'accord avec ça.

> Bob said:
> La seule conf à instancier côté consumer est celle qui décrit où 
> sont les sources de données (leurs driver d'accès et leurs URLs).

Ok c'est une interface+protocole de plus à gérer côté consumer.

> Bob said:
> Le tout est indépendant de TSP dans son API actuelle.
> 

C'est donc bien et pas bien.
Pro:
     on peut browser/préparer des synoptiques sans même être
     connecté à un provider mais juste en chargeant ta BASE avec tes OUTILS.
Cons:
     la liste des symboles dispos d'un provider n'est connu que de ce seul
     provider (ça peut même changer dans le temps...)
 
     ce mécanisme n'est "que" Java.

> Bob said:
> Ce n'est qu'une boîte à outil :

[...]

Je comprends désormais mieux et je intéressé par l'outil.
Toutefois il faudrait à mon sens examiner les liens avec le TSP actuel.

Ce que j'ai essayé de faire dans les lignes précédentes

De cette façon l'utilisation de cette boite à outils dans un consumer 
sera plus "propre".
Quitte à rajouter des choses à TSP, si c'est "nécessaire+raisonnable". 

> Bob said:     
> Quelques bouts de code (le package XDBO n'est pas encore complet, ni encore 
> moins stand-alone, pour te faire une démo) :

 Je regardes le code dès que je peux.


Eric

<<winmail.dat>>