C'est une question peut-être artificielle pour faire un ajout à la
FAQ, mais mon problème est réel, quoique pas urgent.
J'ai un site de généalogie et il y a des millions de pages de
généalogie dans Internet. Pendant plusieurs années, le site
www.gendex.com faisait le tour des sites web et faisait un index
de ces pages. L'auteur a abandonné l'an dernier, sans donner
d'explications.
Il y a eu au moins 2 tentatives pour prendre plus ou moins la suite.
Et quand je dis "la suite", c'est loin d'être la même chose.
Dans un cas, c'est un site qui utilise de façon automatisée une liste
de noms de famille et vérifie si les sites de famille existent. Il
fait de même avec les régions des États-Unis (c'est un site
américain). C'est assez facile à faire puisque dans certains sites
spécialisés, on trouvera par exemple tous les cimetières classés par
état et comté américain, donc il suffit d'avoir la liste des états
et comtés et de vérifier si les répertoires existent, puis d'ajouter
un lien. De même, pour les sites de messages, il suffit de vérifier
si les noms de famille existent à partir d'une liste de référence.
Donc, en peu de temps, on monte un site de référence avec disons un
million de liens. Cela impressionne les visiteurs et attire les clics
sans trop de travail.
Dans un autre cas, c'est une sorte de google qui se limite aux sites
spécialisés. Il y a un robot qui visite les sites et qui relit les
noms, exactement comme google et des centaines d'autres moteurs le
font.
Alors, comment fait-on ce genre de robot qui est une sorte de
navigateur intelligent ?
Ma première réaction serait de monter quelque chose en PHP, de le
lancer en permanence sur un PC qui ne ferait que cela, qui lirait
des pages, qui les digérerait (par exemple, je pourrais supposer
que 2 noms de suite avec une majuscule et dans la même structure
sont des prénoms et noms de famille, ou l'inverse, ou encore, je
pourrais identifier le logiciel utilisé et désassembler selon ce
logiciel).
Mais, je me dis aussi que le PHP est relativement lent et pas
vraiment fait pour cela. Alors, pourquoi pas reprendre le moteur
gecko et en faire ce que je veux ?
Ou bien, utiliser wget de Linux et écrire une moulinette en C++
pour extraire les données ?
Quelle serait donc la meilleure méthode pour faire un tel robot
ou navigateur automatique (autopiloté) ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Fabien LE LEZ
On Mon, 27 Jun 2005 12:05:24 -0400, Denis Beauregard :
Mais, je me dis aussi que le PHP est relativement lent et pas vraiment fait pour cela.
PHP n'est pas forcément si lent que ça. Et AMHA, "décoder" une page HTML est nettement plus rapide que la télécharger.
Alors, pourquoi pas reprendre le moteur gecko et en faire ce que je veux ?
C'est vraiment prendre une bombe atomique pour couper une patte à une mouche. Tu n'as pas besoin d'un moteur de rendu graphique, juste la partie "téléchargement de page web". Et ça, c'est trivial à programmer, voire carrément intégré dans plusieurs langages (dont PHP).
Ou bien, utiliser wget de Linux
wget tout court, non ?
et écrire une moulinette en C++ pour extraire les données ?
C'est vrai que C++ est nettement plus adapté aux chaînes de caractères que C. Mais loin derrière Perl ou PHP tout de même.
Je te conseille de tenter le coup en PHP (ou Perl); si le script se révèle trop lent, tu auras au moins une maquette qui te guidera pour l'implémentation dans un autre langage.
On Mon, 27 Jun 2005 12:05:24 -0400, Denis Beauregard
<denis.b-at-francogene.com@nospam.com>:
Mais, je me dis aussi que le PHP est relativement lent et pas
vraiment fait pour cela.
PHP n'est pas forcément si lent que ça. Et AMHA, "décoder" une page
HTML est nettement plus rapide que la télécharger.
Alors, pourquoi pas reprendre le moteur
gecko et en faire ce que je veux ?
C'est vraiment prendre une bombe atomique pour couper une patte à une
mouche.
Tu n'as pas besoin d'un moteur de rendu graphique, juste la partie
"téléchargement de page web". Et ça, c'est trivial à programmer, voire
carrément intégré dans plusieurs langages (dont PHP).
Ou bien, utiliser wget de Linux
wget tout court, non ?
et écrire une moulinette en C++ pour extraire les données ?
C'est vrai que C++ est nettement plus adapté aux chaînes de caractères
que C. Mais loin derrière Perl ou PHP tout de même.
Je te conseille de tenter le coup en PHP (ou Perl); si le script se
révèle trop lent, tu auras au moins une maquette qui te guidera pour
l'implémentation dans un autre langage.
On Mon, 27 Jun 2005 12:05:24 -0400, Denis Beauregard :
Mais, je me dis aussi que le PHP est relativement lent et pas vraiment fait pour cela.
PHP n'est pas forcément si lent que ça. Et AMHA, "décoder" une page HTML est nettement plus rapide que la télécharger.
Alors, pourquoi pas reprendre le moteur gecko et en faire ce que je veux ?
C'est vraiment prendre une bombe atomique pour couper une patte à une mouche. Tu n'as pas besoin d'un moteur de rendu graphique, juste la partie "téléchargement de page web". Et ça, c'est trivial à programmer, voire carrément intégré dans plusieurs langages (dont PHP).
Ou bien, utiliser wget de Linux
wget tout court, non ?
et écrire une moulinette en C++ pour extraire les données ?
C'est vrai que C++ est nettement plus adapté aux chaînes de caractères que C. Mais loin derrière Perl ou PHP tout de même.
Je te conseille de tenter le coup en PHP (ou Perl); si le script se révèle trop lent, tu auras au moins une maquette qui te guidera pour l'implémentation dans un autre langage.
Emmanuel Florac
Le Mon, 27 Jun 2005 12:05:24 -0400, Denis Beauregard a écrit :
Alors, comment fait-on ce genre de robot qui est une sorte de navigateur intelligent ?
PHP n'est pas très adapté mais pas pour les raisons que tu crois : PHP est mal équipé pour traiter des pages webs comme "client". Mieux vaut utiliser Perl, en particulier avec les extensions LWP::UserAgent, WWWW::Mechanize, HTML::TreeBuilder qui permettent de traiter des sites à distance (y compris de facilement s'enregistrer, soumettre des formulaires, etc).
-- Mais monsieur, voudriez-vous que je me l'écorchasse? Barbey d'Aurevilly.
Le Mon, 27 Jun 2005 12:05:24 -0400, Denis Beauregard a écrit :
Alors, comment fait-on ce genre de robot qui est une sorte de
navigateur intelligent ?
PHP n'est pas très adapté mais pas pour les raisons que tu crois : PHP
est mal équipé pour traiter des pages webs comme "client". Mieux vaut
utiliser Perl, en particulier avec les extensions
LWP::UserAgent, WWWW::Mechanize, HTML::TreeBuilder qui permettent de
traiter des sites à distance (y compris de facilement s'enregistrer,
soumettre des formulaires, etc).
--
Mais monsieur, voudriez-vous que je me l'écorchasse?
Barbey d'Aurevilly.
Le Mon, 27 Jun 2005 12:05:24 -0400, Denis Beauregard a écrit :
Alors, comment fait-on ce genre de robot qui est une sorte de navigateur intelligent ?
PHP n'est pas très adapté mais pas pour les raisons que tu crois : PHP est mal équipé pour traiter des pages webs comme "client". Mieux vaut utiliser Perl, en particulier avec les extensions LWP::UserAgent, WWWW::Mechanize, HTML::TreeBuilder qui permettent de traiter des sites à distance (y compris de facilement s'enregistrer, soumettre des formulaires, etc).
-- Mais monsieur, voudriez-vous que je me l'écorchasse? Barbey d'Aurevilly.
Sergio
Denis Beauregard vient de nous annoncer :
Dans un autre cas, c'est une sorte de google qui se limite aux sites spécialisés. Il y a un robot qui visite les sites et qui relit les noms, exactement comme google et des centaines d'autres moteurs le font.
Alors, comment fait-on ce genre de robot qui est une sorte de navigateur intelligent ?
Perl et Python semblent assez adéquat, lancés régulièrement depuis ton PC.
Tu peux aller faire un tour du côté de la communauté de Wikipédia qui créé des robots pour modifier automatiquement l'encyclopédie : http://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Technique_des_bots
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Denis Beauregard vient de nous annoncer :
Dans un autre cas, c'est une sorte de google qui se limite aux sites
spécialisés. Il y a un robot qui visite les sites et qui relit les
noms, exactement comme google et des centaines d'autres moteurs le
font.
Alors, comment fait-on ce genre de robot qui est une sorte de
navigateur intelligent ?
Perl et Python semblent assez adéquat, lancés régulièrement depuis ton
PC.
Tu peux aller faire un tour du côté de la communauté de Wikipédia qui
créé des robots pour modifier automatiquement l'encyclopédie :
http://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Technique_des_bots
--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
Dans un autre cas, c'est une sorte de google qui se limite aux sites spécialisés. Il y a un robot qui visite les sites et qui relit les noms, exactement comme google et des centaines d'autres moteurs le font.
Alors, comment fait-on ce genre de robot qui est une sorte de navigateur intelligent ?
Perl et Python semblent assez adéquat, lancés régulièrement depuis ton PC.
Tu peux aller faire un tour du côté de la communauté de Wikipédia qui créé des robots pour modifier automatiquement l'encyclopédie : http://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Technique_des_bots
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Ludovic LE MOAL
Denis Beauregard nous a schtroumpfé :
Bonjour,
Bonjour,
Ma première réaction serait de monter quelque chose en PHP, de le lancer en permanence sur un PC qui ne ferait que cela, qui lirait des pages, qui les digérerait (par exemple, je pourrais supposer que 2 noms de suite avec une majuscule et dans la même structure sont des prénoms et noms de famille, ou l'inverse, ou encore, je pourrais identifier le logiciel utilisé et désassembler selon ce logiciel).
C'est la solution que j'aurais choisie. Mais je suppose que les sites visités doivent avoir des trucs pour les sites partenaires, non ? Du style XML, non ? -- Ludovic LE MOAL
Denis Beauregard nous a schtroumpfé :
Bonjour,
Bonjour,
Ma première réaction serait de monter quelque chose en PHP, de le
lancer en permanence sur un PC qui ne ferait que cela, qui lirait
des pages, qui les digérerait (par exemple, je pourrais supposer
que 2 noms de suite avec une majuscule et dans la même structure
sont des prénoms et noms de famille, ou l'inverse, ou encore, je
pourrais identifier le logiciel utilisé et désassembler selon ce
logiciel).
C'est la solution que j'aurais choisie. Mais je suppose que les sites
visités doivent avoir des trucs pour les sites partenaires, non ? Du style
XML, non ?
--
Ludovic LE MOAL
Ma première réaction serait de monter quelque chose en PHP, de le lancer en permanence sur un PC qui ne ferait que cela, qui lirait des pages, qui les digérerait (par exemple, je pourrais supposer que 2 noms de suite avec une majuscule et dans la même structure sont des prénoms et noms de famille, ou l'inverse, ou encore, je pourrais identifier le logiciel utilisé et désassembler selon ce logiciel).
C'est la solution que j'aurais choisie. Mais je suppose que les sites visités doivent avoir des trucs pour les sites partenaires, non ? Du style XML, non ? -- Ludovic LE MOAL
Denis Beauregard
Le 28 Jun 2005 08:41:37 GMT, Ludovic LE MOAL écrivait dans fr.comp.infosystemes.www.navigateurs:
Denis Beauregard nous a schtroumpfé :
Bonjour,
Bonjour,
Ma première réaction serait de monter quelque chose en PHP, de le lancer en permanence sur un PC qui ne ferait que cela, qui lirait des pages, qui les digérerait (par exemple, je pourrais supposer que 2 noms de suite avec une majuscule et dans la même structure sont des prénoms et noms de famille, ou l'inverse, ou encore, je pourrais identifier le logiciel utilisé et désassembler selon ce logiciel).
C'est la solution que j'aurais choisie. Mais je suppose que les sites visités doivent avoir des trucs pour les sites partenaires, non ? Du style XML, non ?
gendex.com utilisait un index en texte produit par certains logiciels. Mais en général, le XML ou tout ce qui est à la mode aujourd'hui dans le monde informatique, c'est encore utopique en généalogie. Il y a une tentative de norme qui s'appelle GedML, pour Gedcom (la vieille norme en généalogie) + XML, mais cela fait plusieurs années qu'on en débat.
De plus, il est de moins en moins recommandé de faciliter la vie aux pilleurs qui revendent les données. Il y a des gens qui prennent des GEDCOM sur les sites et les revendent ou se font une base de données: cela m'est arrivé et j'ai retiré tout Gedcom de mon site depuis. D'ailleurs, mon projet est un index et non de reconstruire les bases de données en question (ce qui serait tout de même beaucoup plus difficile à cause de la multitude de structures différentes).
Denis
Le 28 Jun 2005 08:41:37 GMT, Ludovic LE MOAL <bulle@alussinan.org>
écrivait dans fr.comp.infosystemes.www.navigateurs:
Denis Beauregard nous a schtroumpfé :
Bonjour,
Bonjour,
Ma première réaction serait de monter quelque chose en PHP, de le
lancer en permanence sur un PC qui ne ferait que cela, qui lirait
des pages, qui les digérerait (par exemple, je pourrais supposer
que 2 noms de suite avec une majuscule et dans la même structure
sont des prénoms et noms de famille, ou l'inverse, ou encore, je
pourrais identifier le logiciel utilisé et désassembler selon ce
logiciel).
C'est la solution que j'aurais choisie. Mais je suppose que les sites
visités doivent avoir des trucs pour les sites partenaires, non ? Du style
XML, non ?
gendex.com utilisait un index en texte produit par certains logiciels.
Mais en général, le XML ou tout ce qui est à la mode aujourd'hui dans
le monde informatique, c'est encore utopique en généalogie. Il y a
une tentative de norme qui s'appelle GedML, pour Gedcom (la vieille
norme en généalogie) + XML, mais cela fait plusieurs années qu'on en
débat.
De plus, il est de moins en moins recommandé de faciliter la vie aux
pilleurs qui revendent les données. Il y a des gens qui prennent des
GEDCOM sur les sites et les revendent ou se font une base de données:
cela m'est arrivé et j'ai retiré tout Gedcom de mon site depuis.
D'ailleurs, mon projet est un index et non de reconstruire les bases
de données en question (ce qui serait tout de même beaucoup plus
difficile à cause de la multitude de structures différentes).
Le 28 Jun 2005 08:41:37 GMT, Ludovic LE MOAL écrivait dans fr.comp.infosystemes.www.navigateurs:
Denis Beauregard nous a schtroumpfé :
Bonjour,
Bonjour,
Ma première réaction serait de monter quelque chose en PHP, de le lancer en permanence sur un PC qui ne ferait que cela, qui lirait des pages, qui les digérerait (par exemple, je pourrais supposer que 2 noms de suite avec une majuscule et dans la même structure sont des prénoms et noms de famille, ou l'inverse, ou encore, je pourrais identifier le logiciel utilisé et désassembler selon ce logiciel).
C'est la solution que j'aurais choisie. Mais je suppose que les sites visités doivent avoir des trucs pour les sites partenaires, non ? Du style XML, non ?
gendex.com utilisait un index en texte produit par certains logiciels. Mais en général, le XML ou tout ce qui est à la mode aujourd'hui dans le monde informatique, c'est encore utopique en généalogie. Il y a une tentative de norme qui s'appelle GedML, pour Gedcom (la vieille norme en généalogie) + XML, mais cela fait plusieurs années qu'on en débat.
De plus, il est de moins en moins recommandé de faciliter la vie aux pilleurs qui revendent les données. Il y a des gens qui prennent des GEDCOM sur les sites et les revendent ou se font une base de données: cela m'est arrivé et j'ai retiré tout Gedcom de mon site depuis. D'ailleurs, mon projet est un index et non de reconstruire les bases de données en question (ce qui serait tout de même beaucoup plus difficile à cause de la multitude de structures différentes).
Denis
Ludovic LE MOAL
Denis Beauregard nous a schtroumpfé :
C'est la solution que j'aurais choisie. Mais je suppose que les sites visités doivent avoir des trucs pour les sites partenaires, non ? Du style XML, non ?
gendex.com utilisait un index en texte produit par certains logiciels. Mais en général, le XML ou tout ce qui est à la mode aujourd'hui dans le monde informatique, c'est encore utopique en généalogie. Il y a une tentative de norme qui s'appelle GedML, pour Gedcom (la vieille norme en généalogie) + XML, mais cela fait plusieurs années qu'on en débat.
Ok.
De plus, il est de moins en moins recommandé de faciliter la vie aux pilleurs qui revendent les données. Il y a des gens qui prennent des GEDCOM sur les sites et les revendent ou se font une base de données: cela m'est arrivé et j'ai retiré tout Gedcom de mon site depuis.
Je comprends. L'idée, c'était plus de voir avec les sites partenaires s'ils ne proposaient pas des « sorties » XML.
J'ai fait ça avec mon site : les résultats des recherches peuvent être exportés en XML. Si un autre site est intéressé, je lui file un identifiant et une clef unique (de façon à sécuriser un minimum...) et hop! il a un formulaire de recherche et les résultats provenants de mon site sur son site. Le principe des web-services quoi.
Ce serait plus simple que d'aspirer un site, analyser les données, etc. Plus respectueux aussi : si on utilise une autre solution, ça créé une charge pour le serveur, il y a toujours un peu l'idée de voler les données des autres, etc. Plus pérenne aussi : si l'apparence change, vous êtes obligé de refaire l'ensemble du code. Avec XML, il n'y a pas de raison que ça change.
Ceci dit, il faut évidemment que les sites en question proposent ce genre de service mais pourquoi ne pas commencer par là ? -- Ludovic LE MOAL
Denis Beauregard nous a schtroumpfé :
C'est la solution que j'aurais choisie. Mais je suppose que les sites
visités doivent avoir des trucs pour les sites partenaires, non ? Du
style XML, non ?
gendex.com utilisait un index en texte produit par certains logiciels.
Mais en général, le XML ou tout ce qui est à la mode aujourd'hui dans
le monde informatique, c'est encore utopique en généalogie. Il y a
une tentative de norme qui s'appelle GedML, pour Gedcom (la vieille
norme en généalogie) + XML, mais cela fait plusieurs années qu'on en
débat.
Ok.
De plus, il est de moins en moins recommandé de faciliter la vie aux
pilleurs qui revendent les données. Il y a des gens qui prennent des
GEDCOM sur les sites et les revendent ou se font une base de données:
cela m'est arrivé et j'ai retiré tout Gedcom de mon site depuis.
Je comprends. L'idée, c'était plus de voir avec les sites partenaires
s'ils ne proposaient pas des « sorties » XML.
J'ai fait ça avec mon site : les résultats des recherches peuvent être
exportés en XML. Si un autre site est intéressé, je lui file un
identifiant et une clef unique (de façon à sécuriser un minimum...) et
hop! il a un formulaire de recherche et les résultats provenants de mon
site sur son site. Le principe des web-services quoi.
Ce serait plus simple que d'aspirer un site, analyser les données, etc.
Plus respectueux aussi : si on utilise une autre solution, ça créé une
charge pour le serveur, il y a toujours un peu l'idée de voler les
données des autres, etc. Plus pérenne aussi : si l'apparence change, vous
êtes obligé de refaire l'ensemble du code. Avec XML, il n'y a pas de
raison que ça change.
Ceci dit, il faut évidemment que les sites en question proposent ce genre
de service mais pourquoi ne pas commencer par là ?
--
Ludovic LE MOAL
C'est la solution que j'aurais choisie. Mais je suppose que les sites visités doivent avoir des trucs pour les sites partenaires, non ? Du style XML, non ?
gendex.com utilisait un index en texte produit par certains logiciels. Mais en général, le XML ou tout ce qui est à la mode aujourd'hui dans le monde informatique, c'est encore utopique en généalogie. Il y a une tentative de norme qui s'appelle GedML, pour Gedcom (la vieille norme en généalogie) + XML, mais cela fait plusieurs années qu'on en débat.
Ok.
De plus, il est de moins en moins recommandé de faciliter la vie aux pilleurs qui revendent les données. Il y a des gens qui prennent des GEDCOM sur les sites et les revendent ou se font une base de données: cela m'est arrivé et j'ai retiré tout Gedcom de mon site depuis.
Je comprends. L'idée, c'était plus de voir avec les sites partenaires s'ils ne proposaient pas des « sorties » XML.
J'ai fait ça avec mon site : les résultats des recherches peuvent être exportés en XML. Si un autre site est intéressé, je lui file un identifiant et une clef unique (de façon à sécuriser un minimum...) et hop! il a un formulaire de recherche et les résultats provenants de mon site sur son site. Le principe des web-services quoi.
Ce serait plus simple que d'aspirer un site, analyser les données, etc. Plus respectueux aussi : si on utilise une autre solution, ça créé une charge pour le serveur, il y a toujours un peu l'idée de voler les données des autres, etc. Plus pérenne aussi : si l'apparence change, vous êtes obligé de refaire l'ensemble du code. Avec XML, il n'y a pas de raison que ça change.
Ceci dit, il faut évidemment que les sites en question proposent ce genre de service mais pourquoi ne pas commencer par là ? -- Ludovic LE MOAL
Pierre Goiffon
Ludovic LE MOAL wrote:
Je comprends. L'idée, c'était plus de voir avec les sites partenaires s'ils ne proposaient pas des « sorties » XML.
J'ai fait ça avec mon site : les résultats des recherches peuvent être exportés en XML. Si un autre site est intéressé, je lui file un identifiant et une clef unique (de façon à sécuriser un minimum...) et hop! il a un formulaire de recherche et les résultats provenants de mon site sur son site. Le principe des web-services quoi.
Tout dépend des besoins, mais XML a un gros désavantage : c'est rapidement très volumineux, pour des avantages nuls dans ce cadre (prendre des données d'un partenaire / prestataire / client et les insérer dans sa base - car on ne va vraisemblablement pas faire un appel chez lui à chaque fois que l'on a besoin de l'une de ses données)
Avant de faire un choix de technologie, bien voir ses besoins, comme d'habitude...
Ludovic LE MOAL wrote:
Je comprends. L'idée, c'était plus de voir avec les sites partenaires
s'ils ne proposaient pas des « sorties » XML.
J'ai fait ça avec mon site : les résultats des recherches peuvent être
exportés en XML. Si un autre site est intéressé, je lui file un
identifiant et une clef unique (de façon à sécuriser un minimum...) et
hop! il a un formulaire de recherche et les résultats provenants de mon
site sur son site. Le principe des web-services quoi.
Tout dépend des besoins, mais XML a un gros désavantage : c'est
rapidement très volumineux, pour des avantages nuls dans ce cadre
(prendre des données d'un partenaire / prestataire / client et les
insérer dans sa base - car on ne va vraisemblablement pas faire un appel
chez lui à chaque fois que l'on a besoin de l'une de ses données)
Avant de faire un choix de technologie, bien voir ses besoins, comme
d'habitude...
Je comprends. L'idée, c'était plus de voir avec les sites partenaires s'ils ne proposaient pas des « sorties » XML.
J'ai fait ça avec mon site : les résultats des recherches peuvent être exportés en XML. Si un autre site est intéressé, je lui file un identifiant et une clef unique (de façon à sécuriser un minimum...) et hop! il a un formulaire de recherche et les résultats provenants de mon site sur son site. Le principe des web-services quoi.
Tout dépend des besoins, mais XML a un gros désavantage : c'est rapidement très volumineux, pour des avantages nuls dans ce cadre (prendre des données d'un partenaire / prestataire / client et les insérer dans sa base - car on ne va vraisemblablement pas faire un appel chez lui à chaque fois que l'on a besoin de l'une de ses données)
Avant de faire un choix de technologie, bien voir ses besoins, comme d'habitude...
Ludovic LE MOAL
Pierre Goiffon nous a schtroumpfé :
Tout dépend des besoins, mais XML a un gros désavantage : c'est rapidement très volumineux, pour des avantages nuls dans ce cadre (prendre des données d'un partenaire / prestataire / client et les insérer dans sa base - car on ne va vraisemblablement pas faire un appel chez lui à chaque fois que l'on a besoin de l'une de ses données)
Tout dépend de la fréquence de mise à jour du site effectivement mais là, on est à la limite du pillage de données. Quelles solutions autrement ? -- Ludovic LE MOAL
Pierre Goiffon nous a schtroumpfé :
Tout dépend des besoins, mais XML a un gros désavantage : c'est
rapidement très volumineux, pour des avantages nuls dans ce cadre
(prendre des données d'un partenaire / prestataire / client et les
insérer dans sa base - car on ne va vraisemblablement pas faire un appel
chez lui à chaque fois que l'on a besoin de l'une de ses données)
Tout dépend de la fréquence de mise à jour du site effectivement mais là,
on est à la limite du pillage de données. Quelles solutions autrement ?
--
Ludovic LE MOAL
Tout dépend des besoins, mais XML a un gros désavantage : c'est rapidement très volumineux, pour des avantages nuls dans ce cadre (prendre des données d'un partenaire / prestataire / client et les insérer dans sa base - car on ne va vraisemblablement pas faire un appel chez lui à chaque fois que l'on a besoin de l'une de ses données)
Tout dépend de la fréquence de mise à jour du site effectivement mais là, on est à la limite du pillage de données. Quelles solutions autrement ? -- Ludovic LE MOAL
Pierre Goiffon
Ludovic LE MOAL wrote:
Tout dépend des besoins, mais XML a un gros désavantage : c'est rapidement très volumineux, pour des avantages nuls dans ce cadre
Tout dépend de la fréquence de mise à jour du site effectivement mais là, on est à la limite du pillage de données. Quelles solutions autrement ?
Non, on y arrive vite dès que l'on est éditeur de contenu et que l'on s'est lancé dans une activité de revente de ce contenu ! Les autres solutions... On peut parler de flux de fichiers structurés classiques par exemple... Mais en regard de la motivation de mon message initial : la meilleure solution sera celle qui répondra au mieux aux besoins !
Ludovic LE MOAL wrote:
Tout dépend des besoins, mais XML a un gros désavantage : c'est
rapidement très volumineux, pour des avantages nuls dans ce cadre
Tout dépend de la fréquence de mise à jour du site effectivement mais là,
on est à la limite du pillage de données. Quelles solutions autrement ?
Non, on y arrive vite dès que l'on est éditeur de contenu et que l'on
s'est lancé dans une activité de revente de ce contenu !
Les autres solutions... On peut parler de flux de fichiers structurés
classiques par exemple... Mais en regard de la motivation de mon message
initial : la meilleure solution sera celle qui répondra au mieux aux
besoins !
Tout dépend des besoins, mais XML a un gros désavantage : c'est rapidement très volumineux, pour des avantages nuls dans ce cadre
Tout dépend de la fréquence de mise à jour du site effectivement mais là, on est à la limite du pillage de données. Quelles solutions autrement ?
Non, on y arrive vite dès que l'on est éditeur de contenu et que l'on s'est lancé dans une activité de revente de ce contenu ! Les autres solutions... On peut parler de flux de fichiers structurés classiques par exemple... Mais en regard de la motivation de mon message initial : la meilleure solution sera celle qui répondra au mieux aux besoins !
