Re: [sdx-developers] Sources de documents

[Pierrick Brihaye]

Re,

Martin Sevigny a écrit:

> <sdx:documentSource type="OAIHarvester"
>      adminEmail="address@hidden"
>      url="http://toto/sdx/sdx/oai/sdxtest/sdxworld";>
>
>   <sdx:schedule type="cron" id="sch1">
>     <sdx:hour>3</sdx:hour>
>   </sdx:schedule>
>
>   <sdx:action type="OAIVerb" schedule="sch1"
>         name="ListRecords"
>         metadataPrefix="sdx"/>
>
>   <sdx:pipeline>
>     <sdx:transformation type="XSLT" src="index-oai.xsl"/>
>   </sdx:pipeline>
>
> </sdx:documentSource>

Ca me va... sauf que je verais plutôt <sdx:schedule> comme élément 
supérieur (on est dans la config d'appli, mais bon... comme SDX est 
"documento-centrique").

> <sdx:documentSource type="CVS"
>      protocol="pserver"
>      server="cvs.a.com"
>      repository="/cvshome"
>      username="a"
>      password="b">

...

>   <sdx:action type="update" schedule="sch2"
>         module="my-project">
>     <sdx:includes name="*.xml"/>

Est-ce que lma récupération de classe Ant ne peut pas aider dans la 
définition de "filesets" ?

> Ca pourrait se faire par un élément <sdx:callback>

+1

> Qu'en pensez-vous? Je pense qu'on peut assez aisément refactoriser le
> code OAI actuel pour entrer dans ce moule, et ça laisse beaucoup de
> marge pour des évolutions futures. Ce qui est le plus important
> maintenant, c'est de voir si j'ai rien oublié de majeur dans la
> séparation en source/schedule/action.

A priori, c'est bon : la définition de "callbacks" correspond peu ou 
prou à la demande "dévènements". Je suis même assez d'accord pour que 
l'on puisse greffer ces callbacks un peu partout :-)

Le seul truc qui semble manquer c'est un gestion des fallbacks de 
callbacks :-)

J'y réfléchis...

A+


--
Pierrick Brihaye, informaticien
Service régional de l'Inventaire
DRAC Bretagne
mailto:address@hidden