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

[PAGNOT, Robert]

Je commence à faire ça en couleurs pour pas que l'on se perde :
        Thread N-2
        Thread N-1
        This

-----Original Message-----
From: Eric Noulard [mailto:address@hidden]
Sent: Wednesday, August 30, 2006 2:11 AM
To: Transport Sample Protocol development list
Subject: Re: RE : [Tsp-devel] XML, Databa se et Browse : proposition à TSP

> Soyons clairs,

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

Je sais, je sais ... je fais toujours des efforts !

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

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.

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

100% d'accord.

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.

Non, car la Request_Filtered se base sur le NOM des symboles (en tout cas si je me souviens bien ...).
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".

> 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?

Le provider propose des services type DataBase (pas nécessairement XML !) : une vraie BD, des fichiers quelconques ... + 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ô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 !

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

- 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)

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

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. Ce qui est délicat à faire avec des fichiers de conf.

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).

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

Le tout est indépendant de TSP dans son API actuelle.

Ce n'est qu'une boîte à outil :
        Pour une application, on définit un schéma de données  (un fichier, par exemple, XML si tu veux ...) et le driver d'accès associé.

        Sur chaque provider de l'application, on crée les metadata pour les folders et les symboles sur la base du schéma voulu => collection de fichiers disséminés dans le réseau.

                Certains folders peuvent être communs à toute l'application, et leurs metadata, centralisés quelque part (ou non). Rien n'empêche d'avoir des folders communs qui contiennent des folders spécifiques à plusieurs providers : le jeux des URI permet cela !

       
        Côté consumer, on initialise le XDBO qui se débrouille à parser toutes les sources de données qu'il trouve (selon la conf du consumer), et construit un arbre XML-JDOM avec les metadata trouvées. Sur XDBO, on a des classes Tree/List/Column qui permettent d'afficher judicieusement ces metadata. Ces classes peuvent remonter des events (Click, DoubleClick, Hover, Drag, ...) au conteneur qui fera le boulot nécessaire.

        Rien n'empêche le consumer de compléter les metadata d'un symbole avec ce qu'il trouvera en faisant les "Extended_Information".

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

<<XdbAccess.java>> <<XdbInterface.java>> <<JdbcAccess.java>>
<<XmlElement.java>>

         Obscur-ô-Bob

_______________________________________________
Tsp-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/tsp-devel

---------------------------------------------------------

CE COURRIER ELECTRONIQUE EST A USAGE STRICTEMENT INFORMATIF ET NE SAURAIT ENGAGER DE QUELQUE MANIERE QUE CE SOIT EADS ASTRIUM SAS, NI SES FILIALES.

SI UNE ERREUR DE TRANSMISSION OU UNE ADRESSE ERRONEE A MAL DIRIGE CE COURRIER, MERCI D'EN INFORMER L'EXPEDITEUR EN LUI FAISANT UNE REPONSE PAR COURRIER ELECTRONIQUE DES RECEPTION. SI VOUS N'ETES PAS LE DESTINATAIRE DE CE COURRIER, VOUS NE DEVEZ PAS L'UTILISER, LE CONSERVER, EN FAIRE ETAT, LE DISTRIBUER, LE COPIER, L'IMPRIMER OU EN REVELER LE CONTENU A UNE TIERCE PARTIE.



This email is for information only and will not bind EADS Astrium SAS in any contract or obligation, nor its subsidiaries.

If you have received it in error, please notify the sender by return email. If you are not the addressee of this email, you must not use, keep, disseminate, copy, print or otherwise deal with it.

---------------------------------------------------------

XdbAccess.java
Description: Binary data

XdbInterface.java
Description: Binary data

JdbcAccess.java
Description: Binary data

XmlElement.java
Description: Binary data