OoO En cette matinée ensoleillée du mercredi 28 septembre 2005, vers 09:22, "helios" disait:
je ne preconise pas de faire fonctionne pick comme une base relationnelle classique mais pick en singlevalue est plus performant qu"une base relationnelle classique donc cela serait qu'en meme avantageux de le faire
Tu peux prouver ca ?
demande aux editeurs de system multivalue
Renault dit qu'ils font de meilleures voitures que Peugeot.
le seul probleme est que IBM par exemple ne fait pas que du multivalue il fait aussi les concurents
J'attends donc avec impatience le lien de source IBM qui indique que le multivalue fait du single value plus vite que tout autre SGBD. -- Comme son nom l'indique, la Lyonnaise n'est pas auvergnate, qu'elle le prouve. -+- HC in <http://neuneu.mine.nu> : La cuisine au bug -+-
OoO En cette matinée ensoleillée du mercredi 28 septembre 2005, vers
09:22, "helios" <helios@com02.com> disait:
je ne preconise pas de faire fonctionne pick comme une base
relationnelle classique mais pick en singlevalue est plus
performant qu"une base relationnelle classique donc cela serait
qu'en meme avantageux de le faire
Tu peux prouver ca ?
demande aux editeurs de system multivalue
Renault dit qu'ils font de meilleures voitures que Peugeot.
le seul probleme est que IBM par exemple ne fait pas que du multivalue il
fait aussi les concurents
J'attends donc avec impatience le lien de source IBM qui indique que
le multivalue fait du single value plus vite que tout autre SGBD.
--
Comme son nom l'indique, la Lyonnaise n'est pas auvergnate,
qu'elle le prouve.
-+- HC in <http://neuneu.mine.nu> : La cuisine au bug -+-
OoO En cette matinée ensoleillée du mercredi 28 septembre 2005, vers 09:22, "helios" disait:
je ne preconise pas de faire fonctionne pick comme une base relationnelle classique mais pick en singlevalue est plus performant qu"une base relationnelle classique donc cela serait qu'en meme avantageux de le faire
Tu peux prouver ca ?
demande aux editeurs de system multivalue
Renault dit qu'ils font de meilleures voitures que Peugeot.
le seul probleme est que IBM par exemple ne fait pas que du multivalue il fait aussi les concurents
J'attends donc avec impatience le lien de source IBM qui indique que le multivalue fait du single value plus vite que tout autre SGBD. -- Comme son nom l'indique, la Lyonnaise n'est pas auvergnate, qu'elle le prouve. -+- HC in <http://neuneu.mine.nu> : La cuisine au bug -+-
stephane
On 2005-09-28, helios wrote:
openqm est livre avec des serveurs web et ftp
OpenQM, la premiere base qui s'interface en ftp :)
Ceci dit, tu as un lien qui prouve ton affirmation quelque part ?
on par d'interoperabilite pas de develloppement nouveau sinon tout est possible si tu prends un IN8000 tu peut pas faire tourner java parce qu'il n'a pas de machine virtuel java et qu'il y a pas de moyen de l'implanter sans de lourd develloppement et en gardant le system operationnel
Mais qu'est ce qu'on s'en fout d'un IN8000. Parler d'un truc obsolete depuis 20 ans comme d'une reference, c'est meme plus maintenu.
Dis moi, tu pourrais me donner la date d'aujourd'hui ? c'est parce que je voudrais savoir si un gars aurait pas inventer une machine a remonter dans le temps pour te parler.
la question etait l'interroperabilite dans les hopitaux , et de nombreux hopitaux ont encore des IN8000 donc il faut gerer les IN8000 que IN8000 soit neuf ou vieux n'est pas la question c'est la demande du client
Tu as un lien pour prouver tes dire ?
-- http://www.unices.org Les meilleurs modules de Perl http://www.unices.org/photo/ 250 photos de Singapour, Sydney et Seoul http://artlibre.org/ Free Art License
On 2005-09-28, helios <helios@com02.com> wrote:
openqm est livre avec des serveurs web et ftp
OpenQM, la premiere base qui s'interface en ftp :)
Ceci dit, tu as un lien qui prouve ton affirmation quelque part ?
on par d'interoperabilite pas de develloppement nouveau sinon tout est
possible si tu prends un IN8000 tu peut pas faire tourner java parce qu'il
n'a pas de machine virtuel java et qu'il y a pas de moyen de l'implanter
sans de lourd develloppement et en gardant le system operationnel
Mais qu'est ce qu'on s'en fout d'un IN8000. Parler d'un truc obsolete
depuis 20 ans comme d'une reference, c'est meme plus maintenu.
Dis moi, tu pourrais me donner la date d'aujourd'hui ? c'est parce que
je voudrais savoir si un gars aurait pas inventer une machine a remonter
dans le temps pour te parler.
la question etait l'interroperabilite dans les hopitaux , et de nombreux
hopitaux ont encore des IN8000 donc il faut gerer les IN8000 que IN8000 soit
neuf ou vieux n'est pas la question c'est la demande du client
Tu as un lien pour prouver tes dire ?
--
http://www.unices.org Les meilleurs modules de Perl
http://www.unices.org/photo/ 250 photos de Singapour, Sydney et Seoul
http://artlibre.org/ Free Art License
OpenQM, la premiere base qui s'interface en ftp :)
Ceci dit, tu as un lien qui prouve ton affirmation quelque part ?
on par d'interoperabilite pas de develloppement nouveau sinon tout est possible si tu prends un IN8000 tu peut pas faire tourner java parce qu'il n'a pas de machine virtuel java et qu'il y a pas de moyen de l'implanter sans de lourd develloppement et en gardant le system operationnel
Mais qu'est ce qu'on s'en fout d'un IN8000. Parler d'un truc obsolete depuis 20 ans comme d'une reference, c'est meme plus maintenu.
Dis moi, tu pourrais me donner la date d'aujourd'hui ? c'est parce que je voudrais savoir si un gars aurait pas inventer une machine a remonter dans le temps pour te parler.
la question etait l'interroperabilite dans les hopitaux , et de nombreux hopitaux ont encore des IN8000 donc il faut gerer les IN8000 que IN8000 soit neuf ou vieux n'est pas la question c'est la demande du client
Tu as un lien pour prouver tes dire ?
-- http://www.unices.org Les meilleurs modules de Perl http://www.unices.org/photo/ 250 photos de Singapour, Sydney et Seoul http://artlibre.org/ Free Art License
stephane
On 2005-09-28, helios wrote:
je ne preconise pas de faire fonctionne pick comme une base relationnelle
classique mais pick en singlevalue est plus performant qu"une base relationnelle classique donc cela serait qu'en meme avantageux de le faire
Tu peux prouver ca ? demande aux editeurs de system multivalue
Donc, c'est du vent. D'accord.
-- http://www.unices.org Les meilleurs modules de Perl http://www.unices.org/photo/ 250 photos de Singapour, Sydney et Seoul http://artlibre.org/ Free Art License
On 2005-09-28, helios <helios@com02.com> wrote:
je ne preconise pas de faire fonctionne pick comme une base
relationnelle
classique mais pick en singlevalue est plus performant qu"une base
relationnelle classique donc cela serait qu'en meme avantageux de le
faire
Tu peux prouver ca ?
demande aux editeurs de system multivalue
Donc, c'est du vent. D'accord.
--
http://www.unices.org Les meilleurs modules de Perl
http://www.unices.org/photo/ 250 photos de Singapour, Sydney et Seoul
http://artlibre.org/ Free Art License
je ne preconise pas de faire fonctionne pick comme une base relationnelle
classique mais pick en singlevalue est plus performant qu"une base relationnelle classique donc cela serait qu'en meme avantageux de le faire
Tu peux prouver ca ? demande aux editeurs de system multivalue
Donc, c'est du vent. D'accord.
-- http://www.unices.org Les meilleurs modules de Perl http://www.unices.org/photo/ 250 photos de Singapour, Sydney et Seoul http://artlibre.org/ Free Art License
stephane
On 2005-09-28, helios wrote:
On parlait d'inter-operabilite, tu as un lien vers les API Perl, PHP, Python, Java, Ruby et C pour s'interfacer avec ton SGBD ?
http://helios.services.free.fr/openqm/
Je ne vois qu'un serveur web mal securisee, aucune page d'accueil et aucun lien vers les dites API.
et l'interoperabilite c'est pas vers un language mais une base de donnees ou des fichiers
Ca c'est TA definition. L'interoperabilite, c'est vers de n'importe quoi vers n'importe quoi et une base de donnees qui ne sait pas parler avec les languages majeurs a un niveau inter-operabilite nul.
accuterm assure une interoperabilite vers tout les formats courrant de fichiers
Je m'en fous des formats courants de fichiers. Ce qui m'interesse c'est que ca tourne avec mes outils, pas avec des fichiers access ou CSV.
-- http://www.unices.org Les meilleurs modules de Perl http://www.unices.org/photo/ 250 photos de Singapour, Sydney et Seoul http://artlibre.org/ Free Art License
On 2005-09-28, helios <helios@com02.com> wrote:
On parlait d'inter-operabilite, tu as un lien vers les API Perl, PHP,
Python, Java, Ruby et C pour s'interfacer avec ton SGBD ?
http://helios.services.free.fr/openqm/
Je ne vois qu'un serveur web mal securisee, aucune page d'accueil et
aucun lien vers les dites API.
et l'interoperabilite c'est pas vers un language mais une base de donnees ou
des fichiers
Ca c'est TA definition. L'interoperabilite, c'est vers de n'importe quoi
vers n'importe quoi et une base de donnees qui ne sait pas parler avec
les languages majeurs a un niveau inter-operabilite nul.
accuterm assure une interoperabilite vers tout les formats courrant de
fichiers
Je m'en fous des formats courants de fichiers. Ce qui m'interesse c'est
que ca tourne avec mes outils, pas avec des fichiers access ou CSV.
--
http://www.unices.org Les meilleurs modules de Perl
http://www.unices.org/photo/ 250 photos de Singapour, Sydney et Seoul
http://artlibre.org/ Free Art License
On parlait d'inter-operabilite, tu as un lien vers les API Perl, PHP, Python, Java, Ruby et C pour s'interfacer avec ton SGBD ?
http://helios.services.free.fr/openqm/
Je ne vois qu'un serveur web mal securisee, aucune page d'accueil et aucun lien vers les dites API.
et l'interoperabilite c'est pas vers un language mais une base de donnees ou des fichiers
Ca c'est TA definition. L'interoperabilite, c'est vers de n'importe quoi vers n'importe quoi et une base de donnees qui ne sait pas parler avec les languages majeurs a un niveau inter-operabilite nul.
accuterm assure une interoperabilite vers tout les formats courrant de fichiers
Je m'en fous des formats courants de fichiers. Ce qui m'interesse c'est que ca tourne avec mes outils, pas avec des fichiers access ou CSV.
-- http://www.unices.org Les meilleurs modules de Perl http://www.unices.org/photo/ 250 photos de Singapour, Sydney et Seoul http://artlibre.org/ Free Art License
Bruno Patri
In article <43390b73$0$22391$, Bruno Patri wrote:
J'ai rien compris. Le pdf est un format ouvert et donc n'importe qui peut ecrrire une application pour n'importe quelle plate-forme pour lire ou générer un pdf (et d'ailleurs ces applications existent). A partir du momment ou on utilise un standard ouvert (protocole ou format documenté et libre, comme TCP, HTTP, HTML, XML, etc) c'est interopérable.
En tout cas tu as compris mon exemple :)
Mais j'essaie de vérifier les dires de l'auteur du bouquin qui prétend trois choses :
- Ce qui n'est pas interface utilisateur graphique (avec voix etc.) est technologiquement mort car géoéconomiquement mort. Ca dépasse de loin les histoires de formats de fichiers. En gros, on ne peut pas prévoir quel sera l'utilisateur. Si on peut le faire, on est largué stratégiquement.
C'est justement parce que l'on ne peut prevoir quel sera l'utilisateur que les formats de fichiers et les protocoles de communication sont AMHA fondammentaux.
- Ce qui n'est pas objet (et en fait, il dit "java" par la suite) est aussi en gros mort : si on ne peut être certain qu'il y a au moins dans des technologies très diverses une base java, on est presque certain que les appareils ne vont pas pouvoir coopérer. Et là, économiquement encore, c'est mort car c'est devenu trop dangereux d'espérer s'en apercevoir au moment où l'opportunité se présente. (Le cas 1ere Guerre du Golfe par exemple).
Si on parle de la technologie utilisée pour développer une application, je ne vois pas en quoi Java ou la POO serait un gage d'interopérabilité. Encore une fois c'est une question de standards. C ou C++ par exemple sont également publics et documentés, il existe donc des compilateurs pour les différentes plate-formes, permettant a partir des m^mes bases de code de générer des applications portables et intéropérables.
- Ce qui doit être interopérable est économiquement et techniquement totalement imprévisible. Si c'est prévisible, c'est presque que l'information ne vaut plus rien économiquement.
Là je commence à entrevoir le point de vue de l'auteur : ce qui est intéropérable ne vaut rien économiquement car je ne peut plus vendre ma solution propriétaire fermée ? Autrement dit une information qui serait librement accessible à partir de plate-forme et d'outils divers n'aurait pas de valeur économique ? Cela me parait etre une connerie monumentale...
In article <43390b73$0$22391$626a14ce@news.free.fr>, Bruno Patri wrote:
J'ai rien compris. Le pdf est un format ouvert et donc n'importe qui
peut ecrrire une application pour n'importe quelle plate-forme pour lire
ou générer un pdf (et d'ailleurs ces applications existent). A partir du
momment ou on utilise un standard ouvert (protocole ou format documenté
et libre, comme TCP, HTTP, HTML, XML, etc) c'est interopérable.
En tout cas tu as compris mon exemple :)
Mais j'essaie de vérifier les dires de l'auteur du bouquin qui
prétend trois choses :
- Ce qui n'est pas interface utilisateur graphique (avec voix etc.) est
technologiquement mort car géoéconomiquement mort. Ca dépasse de loin les
histoires de formats de fichiers. En gros, on ne peut pas prévoir quel
sera l'utilisateur. Si on peut le faire, on est largué stratégiquement.
C'est justement parce que l'on ne peut prevoir quel sera l'utilisateur
que les formats de fichiers et les protocoles de communication sont AMHA
fondammentaux.
- Ce qui n'est pas objet (et en fait, il dit "java" par la suite) est aussi
en gros mort : si on ne peut être certain qu'il y a au moins dans des
technologies très diverses une base java, on est presque certain que les
appareils ne vont pas pouvoir coopérer. Et là, économiquement encore, c'est
mort car c'est devenu trop dangereux d'espérer s'en apercevoir au moment
où l'opportunité se présente. (Le cas 1ere Guerre du Golfe par exemple).
Si on parle de la technologie utilisée pour développer une application,
je ne vois pas en quoi Java ou la POO serait un gage d'interopérabilité.
Encore une fois c'est une question de standards. C ou C++ par exemple
sont également publics et documentés, il existe donc des compilateurs
pour les différentes plate-formes, permettant a partir des m^mes bases
de code de générer des applications portables et intéropérables.
- Ce qui doit être interopérable est économiquement et techniquement
totalement imprévisible. Si c'est prévisible, c'est presque que l'information
ne vaut plus rien économiquement.
Là je commence à entrevoir le point de vue de l'auteur : ce qui est
intéropérable ne vaut rien économiquement car je ne peut plus vendre ma
solution propriétaire fermée ? Autrement dit une information qui serait
librement accessible à partir de plate-forme et d'outils divers n'aurait
pas de valeur économique ? Cela me parait etre une connerie monumentale...
J'ai rien compris. Le pdf est un format ouvert et donc n'importe qui peut ecrrire une application pour n'importe quelle plate-forme pour lire ou générer un pdf (et d'ailleurs ces applications existent). A partir du momment ou on utilise un standard ouvert (protocole ou format documenté et libre, comme TCP, HTTP, HTML, XML, etc) c'est interopérable.
En tout cas tu as compris mon exemple :)
Mais j'essaie de vérifier les dires de l'auteur du bouquin qui prétend trois choses :
- Ce qui n'est pas interface utilisateur graphique (avec voix etc.) est technologiquement mort car géoéconomiquement mort. Ca dépasse de loin les histoires de formats de fichiers. En gros, on ne peut pas prévoir quel sera l'utilisateur. Si on peut le faire, on est largué stratégiquement.
C'est justement parce que l'on ne peut prevoir quel sera l'utilisateur que les formats de fichiers et les protocoles de communication sont AMHA fondammentaux.
- Ce qui n'est pas objet (et en fait, il dit "java" par la suite) est aussi en gros mort : si on ne peut être certain qu'il y a au moins dans des technologies très diverses une base java, on est presque certain que les appareils ne vont pas pouvoir coopérer. Et là, économiquement encore, c'est mort car c'est devenu trop dangereux d'espérer s'en apercevoir au moment où l'opportunité se présente. (Le cas 1ere Guerre du Golfe par exemple).
Si on parle de la technologie utilisée pour développer une application, je ne vois pas en quoi Java ou la POO serait un gage d'interopérabilité. Encore une fois c'est une question de standards. C ou C++ par exemple sont également publics et documentés, il existe donc des compilateurs pour les différentes plate-formes, permettant a partir des m^mes bases de code de générer des applications portables et intéropérables.
- Ce qui doit être interopérable est économiquement et techniquement totalement imprévisible. Si c'est prévisible, c'est presque que l'information ne vaut plus rien économiquement.
Là je commence à entrevoir le point de vue de l'auteur : ce qui est intéropérable ne vaut rien économiquement car je ne peut plus vendre ma solution propriétaire fermée ? Autrement dit une information qui serait librement accessible à partir de plate-forme et d'outils divers n'aurait pas de valeur économique ? Cela me parait etre une connerie monumentale...
helios
a écrit dans le message de news:
On 2005-09-28, helios wrote:
openqm est livre avec des serveurs web et ftp
OpenQM, la premiere base qui s'interface en ftp :)
Ceci dit, tu as un lien qui prouve ton affirmation quelque part ?
on par d'interoperabilite pas de develloppement nouveau sinon tout est possible si tu prends un IN8000 tu peut pas faire tourner java parce qu'il
n'a pas de machine virtuel java et qu'il y a pas de moyen de l'implanter sans de lourd develloppement et en gardant le system operationnel
Mais qu'est ce qu'on s'en fout d'un IN8000. Parler d'un truc obsolete depuis 20 ans comme d'une reference, c'est meme plus maintenu.
Dis moi, tu pourrais me donner la date d'aujourd'hui ? c'est parce que je voudrais savoir si un gars aurait pas inventer une machine a remonter dans le temps pour te parler.
la question etait l'interroperabilite dans les hopitaux , et de nombreux hopitaux ont encore des IN8000 donc il faut gerer les IN8000 que IN8000 soit
neuf ou vieux n'est pas la question c'est la demande du client
Tu as un lien pour prouver tes dire ?
OUI
<stephane@unices.org> a écrit dans le message de
news:581q03-1v2.ln1@macos.unices.org...
On 2005-09-28, helios <helios@com02.com> wrote:
openqm est livre avec des serveurs web et ftp
OpenQM, la premiere base qui s'interface en ftp :)
Ceci dit, tu as un lien qui prouve ton affirmation quelque part ?
on par d'interoperabilite pas de develloppement nouveau sinon tout est
possible si tu prends un IN8000 tu peut pas faire tourner java parce
qu'il
n'a pas de machine virtuel java et qu'il y a pas de moyen de l'implanter
sans de lourd develloppement et en gardant le system operationnel
Mais qu'est ce qu'on s'en fout d'un IN8000. Parler d'un truc obsolete
depuis 20 ans comme d'une reference, c'est meme plus maintenu.
Dis moi, tu pourrais me donner la date d'aujourd'hui ? c'est parce que
je voudrais savoir si un gars aurait pas inventer une machine a remonter
dans le temps pour te parler.
la question etait l'interroperabilite dans les hopitaux , et de nombreux
hopitaux ont encore des IN8000 donc il faut gerer les IN8000 que IN8000
soit
neuf ou vieux n'est pas la question c'est la demande du client
OpenQM, la premiere base qui s'interface en ftp :)
Ceci dit, tu as un lien qui prouve ton affirmation quelque part ?
on par d'interoperabilite pas de develloppement nouveau sinon tout est possible si tu prends un IN8000 tu peut pas faire tourner java parce qu'il
n'a pas de machine virtuel java et qu'il y a pas de moyen de l'implanter sans de lourd develloppement et en gardant le system operationnel
Mais qu'est ce qu'on s'en fout d'un IN8000. Parler d'un truc obsolete depuis 20 ans comme d'une reference, c'est meme plus maintenu.
Dis moi, tu pourrais me donner la date d'aujourd'hui ? c'est parce que je voudrais savoir si un gars aurait pas inventer une machine a remonter dans le temps pour te parler.
la question etait l'interroperabilite dans les hopitaux , et de nombreux hopitaux ont encore des IN8000 donc il faut gerer les IN8000 que IN8000 soit
neuf ou vieux n'est pas la question c'est la demande du client
Tu as un lien pour prouver tes dire ?
OUI
seb666fr2
helios wrote:
"Emmanuel Florac" a écrit dans le message de news:
qui est intertechnique a ton avis ?
Une boîte qui a été absorbée par Siemens en 1989. Les IN8800 da tent donc au plus tard de 1989...
-- non car siemmens a garder les appellations IN
sinon les dernieres Citroen sont de 1974 quand SIMCA a rachete Citroen et les derniere TALBOT de 1978 quand PSA a rachete SIMCA avec des fonds publ ic
ce qui est vraiment poilant avec cet abruti c'est qu'il passe son temps à parler du passé.
helios wrote:
"Emmanuel Florac" <eflorac@imaginet.fr> a écrit dans le message de
news:pan.2005.09.28.06.45.04.603909@imaginet.fr...
qui est intertechnique a ton avis ?
Une boîte qui a été absorbée par Siemens en 1989. Les IN8800 da tent
donc au plus tard de 1989...
--
non car siemmens a garder les appellations IN
sinon les dernieres Citroen sont de 1974 quand SIMCA a rachete Citroen et
les derniere TALBOT de 1978 quand PSA a rachete SIMCA avec des fonds publ ic
ce qui est vraiment poilant avec cet abruti c'est qu'il passe son temps
à parler du passé.
"Emmanuel Florac" a écrit dans le message de news:
qui est intertechnique a ton avis ?
Une boîte qui a été absorbée par Siemens en 1989. Les IN8800 da tent donc au plus tard de 1989...
-- non car siemmens a garder les appellations IN
sinon les dernieres Citroen sont de 1974 quand SIMCA a rachete Citroen et les derniere TALBOT de 1978 quand PSA a rachete SIMCA avec des fonds publ ic
ce qui est vraiment poilant avec cet abruti c'est qu'il passe son temps à parler du passé.
helios
a écrit dans le message de news:
On 2005-09-28, helios wrote:
On parlait d'inter-operabilite, tu as un lien vers les API Perl, PHP, Python, Java, Ruby et C pour s'interfacer avec ton SGBD ?
http://helios.services.free.fr/openqm/
Je ne vois qu'un serveur web mal securisee,
ils vont etre content chez un des premier operateur internet de France mais l'opinion d'un clown a singapour ne va pas les toucher a mon avis
aucune page d'accueil et aucun lien vers les dites API.
les api y sont en libre services si tu es trop nul pour les prendre c'est ton probleme
et l'interoperabilite c'est pas vers un language mais une base de donnees ou
des fichiers
Ca c'est TA definition. L'interoperabilite, c'est vers de n'importe quoi vers n'importe quoi et une base de donnees qui ne sait pas parler avec les languages majeurs a un niveau inter-operabilite nul.
c'est pas ma definition c'est la definition http://fr.wikipedia.org/wiki/Interop%C3%A9rabilit%C3%A9
accuterm assure une interoperabilite vers tout les formats courrant de fichiers
Je m'en fous des formats courants de fichiers. Ce qui m'interesse c'est que ca tourne avec mes outils, pas avec des fichiers access ou CSV.
le monde en à rien a cirer de tes outils qui n'ont pas d'interoperabilite si
tes outils ne savent travailler avec les formats normalise a toi de les adapte c'est pas la norme qui va s'adapter a tes merdes
<stephane@unices.org> a écrit dans le message de
news:um1q03-1v2.ln1@macos.unices.org...
On 2005-09-28, helios <helios@com02.com> wrote:
On parlait d'inter-operabilite, tu as un lien vers les API Perl, PHP,
Python, Java, Ruby et C pour s'interfacer avec ton SGBD ?
http://helios.services.free.fr/openqm/
Je ne vois qu'un serveur web mal securisee,
ils vont etre content chez un des premier operateur internet de France mais
l'opinion d'un clown a singapour ne va pas les toucher a mon avis
aucune page d'accueil et aucun lien vers les dites API.
les api y sont en libre services si tu es trop nul pour les prendre c'est
ton probleme
et l'interoperabilite c'est pas vers un language mais une base de
donnees ou
des fichiers
Ca c'est TA definition. L'interoperabilite, c'est vers de n'importe quoi
vers n'importe quoi et une base de donnees qui ne sait pas parler avec
les languages majeurs a un niveau inter-operabilite nul.
c'est pas ma definition c'est la definition
http://fr.wikipedia.org/wiki/Interop%C3%A9rabilit%C3%A9
accuterm assure une interoperabilite vers tout les formats courrant de
fichiers
Je m'en fous des formats courants de fichiers. Ce qui m'interesse c'est
que ca tourne avec mes outils, pas avec des fichiers access ou CSV.
le monde en à rien a cirer de tes outils qui n'ont pas d'interoperabilite si
tes outils ne savent travailler avec les formats normalise a toi de les
adapte c'est pas la norme qui va s'adapter a tes merdes
On parlait d'inter-operabilite, tu as un lien vers les API Perl, PHP, Python, Java, Ruby et C pour s'interfacer avec ton SGBD ?
http://helios.services.free.fr/openqm/
Je ne vois qu'un serveur web mal securisee,
ils vont etre content chez un des premier operateur internet de France mais l'opinion d'un clown a singapour ne va pas les toucher a mon avis
aucune page d'accueil et aucun lien vers les dites API.
les api y sont en libre services si tu es trop nul pour les prendre c'est ton probleme
et l'interoperabilite c'est pas vers un language mais une base de donnees ou
des fichiers
Ca c'est TA definition. L'interoperabilite, c'est vers de n'importe quoi vers n'importe quoi et une base de donnees qui ne sait pas parler avec les languages majeurs a un niveau inter-operabilite nul.
c'est pas ma definition c'est la definition http://fr.wikipedia.org/wiki/Interop%C3%A9rabilit%C3%A9
accuterm assure une interoperabilite vers tout les formats courrant de fichiers
Je m'en fous des formats courants de fichiers. Ce qui m'interesse c'est que ca tourne avec mes outils, pas avec des fichiers access ou CSV.
le monde en à rien a cirer de tes outils qui n'ont pas d'interoperabilite si
tes outils ne savent travailler avec les formats normalise a toi de les adapte c'est pas la norme qui va s'adapter a tes merdes
helios
a écrit dans le message de news:
On 2005-09-28, helios wrote:
je ne preconise pas de faire fonctionne pick comme une base relationnelle
classique mais pick en singlevalue est plus performant qu"une base relationnelle classique donc cela serait qu'en meme avantageux de le faire
Tu peux prouver ca ? demande aux editeurs de system multivalue
Donc, c'est du vent. D'accord.
tu paie combien pour que je fasses ce travail de recherches a ta place car
c'est toi qui a besoin du lien pas moi?
<stephane@unices.org> a écrit dans le message de
news:bf1q03-1v2.ln1@macos.unices.org...
On 2005-09-28, helios <helios@com02.com> wrote:
je ne preconise pas de faire fonctionne pick comme une base
relationnelle
classique mais pick en singlevalue est plus performant qu"une base
relationnelle classique donc cela serait qu'en meme avantageux de le
faire
Tu peux prouver ca ?
demande aux editeurs de system multivalue
Donc, c'est du vent. D'accord.
tu paie combien pour que je fasses ce travail de recherches a ta place car
je ne preconise pas de faire fonctionne pick comme une base relationnelle
classique mais pick en singlevalue est plus performant qu"une base relationnelle classique donc cela serait qu'en meme avantageux de le faire
Tu peux prouver ca ? demande aux editeurs de system multivalue
Donc, c'est du vent. D'accord.
tu paie combien pour que je fasses ce travail de recherches a ta place car
c'est toi qui a besoin du lien pas moi?
helios
a écrit dans le message de news:
On 2005-09-28, Didier Couderc wrote:
J'ai fait un stage chez Intertechnique à Plaisir il y a 20 ans. Ils avaient bien une activité Pick, ils fabriquaient / assemblaient bien des machines à processeurs 68k.
C'est amusant de parler d'histoire ancienne comme ca :)
les concepts "revolutionaire" de 2005 dans le web sont des theories mathematiques de plus de 200ans alors ......
les algorythmes de tris dernier cris on plus de 40ans meme chose pour les algo de compression alors les systemes morveux ayant du lait aux naseaux peuvent allez a la casse
en 1980 une machine 8086 demarait en moins de 30seconde en bootant sur disquette un MSDOS en 2005 un athlon64-4800 bicoeur met plus de 3 minutes à demarer windows depuis un disque dur
<stephane@unices.org> a écrit dans le message de
news:rvtp03-3q2.ln1@macos.unices.org...
On 2005-09-28, Didier Couderc <Didier.Couderc@alussinan.org> wrote:
J'ai fait un stage chez Intertechnique à Plaisir il y a 20 ans. Ils
avaient bien une activité Pick, ils fabriquaient / assemblaient bien
des machines à processeurs 68k.
C'est amusant de parler d'histoire ancienne comme ca :)
les concepts "revolutionaire" de 2005 dans le web sont des theories
mathematiques de plus de 200ans alors ......
les algorythmes de tris dernier cris on plus de 40ans meme chose pour les
algo de compression alors les systemes morveux ayant du lait aux naseaux
peuvent allez a la casse
en 1980 une machine 8086 demarait en moins de 30seconde en bootant sur
disquette un MSDOS
en 2005 un athlon64-4800 bicoeur met plus de 3 minutes à demarer windows
depuis un disque dur
J'ai fait un stage chez Intertechnique à Plaisir il y a 20 ans. Ils avaient bien une activité Pick, ils fabriquaient / assemblaient bien des machines à processeurs 68k.
C'est amusant de parler d'histoire ancienne comme ca :)
les concepts "revolutionaire" de 2005 dans le web sont des theories mathematiques de plus de 200ans alors ......
les algorythmes de tris dernier cris on plus de 40ans meme chose pour les algo de compression alors les systemes morveux ayant du lait aux naseaux peuvent allez a la casse
en 1980 une machine 8086 demarait en moins de 30seconde en bootant sur disquette un MSDOS en 2005 un athlon64-4800 bicoeur met plus de 3 minutes à demarer windows depuis un disque dur
