El Titi a écrit 3948 commentaires

Qu'il ait raison sur le fond ne change rien à la forme. Qu'ils viennent le signifier aux autres est juste un comble.
C'est tout.

Question respect, sans arrogance ! Tu en connais un rayon !

L’hôpital qui se fout de la charité.

Faut dire tout de suite ca part dans du jabber.

Elles n'ont pas l'esprit "Lean Startup", les moules du bouchot.
Pas étonnnant que Non ne veuille pas s'y coller

L'intérêt est pourtant certain: passer d'un communauté virtuelle au réel.

Dommage

Ah oui

Intuitivement on s'attendrait à le trouver sur la page de suivi mais c'est ok

Y'a pas de recherche dans le suivi, non ?

Oui mais de manière pragmatique:

Là dans une entrée de forum:
http://linuxfr.org/forums/general-general/posts/premiers-linux-magazine-a-donner-sur-toulouse

j'aimerais rencontrer qq1 pour lui remettre des bouquins.
Pas un besoin sophistiqué.

Là en fait on n'a pas moyen de contacter quelqu'un sans balancer son contact à la terre entière.
Y'a un ticket dans suivi (Y'a pas de recherche non plus)
2 features intéressantes pourtant

Ca pouvait être pratique pourtant.

Ca n'existe plus les messages privé sur DLFP ?
Je peux faire un détour par Basso si c'est trop compliqué pour les assoces.

Anéfé !

Et pour tout ce qui tourne autour du model driven avec Eclipse,
vas plutôt voir par ici:
http://www.eclipse.org/modeling/

Tout se base sur l'Ecore
http://download.eclipse.org/modeling/emf/emf/javadoc/2.9.0/org/eclipse/emf/ecore/package-summary.html#details
qui est lui-même une implémentation d'une sous-partie du MOF (http://www.omg.org/mof/)

Non je vais voir avec eux ou avec Toulibre.
Merci pour l'info

Et pour l'ambition démesurée:

Ne confonds pas MDA (http://en.wikipedia.org/wiki/Model-driven_architecture) qui fonde l'architecture sur les modèles avec une approche purement top-down et le MDSD (http://en.wikipedia.org/wiki/Model_Driven_Software_Development) qui en fait un usage plus pragmatique.
Les techniques Model-Driven peuvent s'avérer très efficaces utilisées à bon escient y compris pour écrire son propre DSL textuel (Son langage personnalisé).

Jette un coup d'oeil à Xtext:
tutoriel
http://alain-bernard.developpez.com/tutoriels/eclipse/creation-grammaire-xtext/
Site officiel:
https://www.eclipse.org/Xtext/

Relis mon paragraphe plus haut.
Un bon métamodèle et un langage de transfo sont bien plus efficaces.
J'avais testé le XSLT et c'était contreproductif pour notre besoin et pas adapté.
Si tu as cette problématique tourne toi vers des gens compétents.
Il y sûrement des personnes d'Obeo qui traînent par ici prêtes à t'apporter du conseil ou des solutions.
(Sinon envoie un MP)

AMQP à l'air d'être initiative intéressante elle n'a pas l'air d'avoir fédéré beaucoup de monde.

ZeroC introduit plus de couplage et retombe dans les travers de CORBA, il me semble. Ce protocole est trés ancine et n'a jamais vraiment percé. Elles se basent sur les données.

Les autres n'adressent que Java et ne sont donc pas agnostiques

XMPP j'ai du mal à voir comment ca pourrait s'appliquer mais pourquoi pas.

Enfin un autr initailtive que j'aime bien est OSLC ( http://open-services.net/ )
Ca adresse un bus de service ALM (Application Lifcycle Management) est c'est poussé par IBM avec leur plateforme Jazz/RTC.

Mais le core s'appuid sur des ressources en guise de données avec RDF et ca se construit au dessus d'une archi REST.
REST seule est très limité pour le transactionnel.

Pour l'UDDI tu as sans doute raison, en revanche le WSDL est très utilisés.
Et le REST ne résoud pas tout dans des transactions B2B complexes.

La volonté de baser un ESB sur du SOAP pour des web-services interne part d'un bon sentiment. Une réutilisation potentielle en externe à coup de BPEL s'il le faut.

Dans ma boîte, nous avions implémenté un bus de service des années avant la hype SOA et son standard. Il a fallu tout migrer vers un ESB proprio.
C'est un fiasco en terme de réutilisation de service car aucune gouvernance n'a été sérieusement entreprise.
Aujourd'hui, on aimerait se tourner ves un ESB open-source.

Je crois que le mirage du SOA vient surtout du fait que les daicideurs pressés ont imaginé decrire les processus métiers en BPMN, appuyer sur un boutons et virer les DSI.
Mais ca n'a rien à voir avec les caractéristiques du SOAP.

Mais merci d'avoir développé ton point de vue

Justement non.

Ce sont des des langages déclaratifs à la base. Rien à voir avec le XSLT.

La puissance du MDD vient du du meta-metamodel MOF (Meta Object Facility) de l'OMG ( qui permet de décrire tout langage de modélisation standard ou DSLs (Domain Specific Lanaguage).
Son implémentation dans Eclipse est l'Ecore. EMF (Eclipse Modeling Framework) fournit toutes les facilités pour décrire les métamodèles des langages et les manipuler.
Pour une transformation, il faut donc décrire les metamodèles de départ (des cartridges existent pour les standards)et d'arrivée. Ca génère automatiquement tout le code de manipulation des modèles, puis écrire une transformation dans un des langage pré-cités (ATL et pas ATI d'ailleurs pas facile avec une tablette et son auto-correction).
Ces langages sont beaucoup plus compréhensibles et puissants que du XSLT.

Le XML n'est qu'un format de persistence. Tout se fait en mémoire avec une API adéquate. Et tout ca peut être beaucoup plus rapidement mis en place qu'avec du XSLT.

Pour du M2T Model 2 Text, tu utilse un langage de template.
Tu écrit ton texte final statique et à certains endroits tu "injectes" le code pour aller chercher les bonnes infos dans ton modèles source.

Le seuls truc qui reste merdique est la génération documentaire.
Avec le code on peut laisser la place à des balises protected pour que le code puisse être modidfié et par ecrasé lors des générations ultérieures. Avec un document Word ou odf ce n'est pas possible.

La déchetterie de mon village accueillera donc ces cartons bras ouverts

Dsl, je n'escompte pas péter à Lyon dans un avenir proche.
Dommage

Oui enfin, Linux Mag, culturellement, ça n'a pas grand chose à voir avec Marguerite Duras ou Nino Ferrer ( http://www.bibliotheque.toulouse.fr/NinoFerrer.html )
Mais merci du conseil

Et pour des échanges B2B?

Pour du M2M (model tout model) tu as ATl oub xTend de open architectureware (sous eclipse maintenant). Pour du model to text: oaw xPand, Acceleo,…

Donc XSLT est tellement incompréhensible qu'il faut passer par des outils pour pouvoir l'utiliser. Ça démontre bien la simplicité de "truc".

Qu'est ce qui remplace SOAP pour du SOA aujourd'hui ?
Mis à part le fait de publier son API sous REsT je ne vois guère. Ce n'est plus du SOA.
Et tu n'as toujours pas répondu : mal gaulé ça n'avance pas à grand chose comme argument.

Je trouve certaines qualités a XML que tu considères comme des défauts et à l'inverse les usages que tu cites ne me paraissent pas pertinents.

XSLT est simplement une hérésie en terme de langage de transformation pour n'importe qui a déjà fait un peu de model driven. Il est inutilement compliqué et limité même pour des transformations de modèle a modèle persisté en XML et ne parlons pas de la génération de code depuis un modele. Utiliser un langage à balises pour décrire des traitement, quelle idée saugrenue à part de vouloir faire rentrer le monde dans le même moule.
Autant utiliser du PHP pour faire un script tiens (vendredi tout est permis)

Et que reproche tu à SOAP exactement?
Hormis le fait que le REST apporte la simplification de l'architecture moyennant du stateless, SOAP est une grande avancée pour les échanges interopérables et correspond exactement à l'usage dévolu au XML. Des services plutôt que des objets avec Corba c'est plutôt positif, non ?
Moins de couplage, moins de contraintes d'architecture…
Bref, précise ta pensée.

Ton commentaire est certainement le plus intéressant du fil et pose une excellente question ?
A quoi est censée servir une monnaie.
Pour échanger biens et services, il y a le troc mais il montre ses limites.
Si l'on peut utiliser un intermédiaire dont la valeur est universellement… Relativement acceptée pour ces échanges, l'économie ne s'en porte que mieux.
Elle se doit de ne pas être créé sans effort sinon sa valeur s'effondre et sa volatilité est assurée.
La rareté semble intrinsèque ce qui donne sa valeur a l'or et autres matériaux.
Problème la rareté de matériaux tangible ne s'adapte pas a l'échelle de l'économie.
Si une autorité unanimement reconnue (une banque centrale, un etat)décide d'émettre cet intermédiaire, l'économie est plus fluide. La rareté est remplacée par la confiance. Que se passe t'il si elle s'effondre ?
Je préfère la rareté personnellement.
Monnaie scripturale ou non, le risque de se faire déposséder de manière illicite perdure.

Le bitcoin concilie la rareté inhérente à une monnaie (l'émission de gaz sur laquelle tu ironises, pareil pour le diamant ?) avec 2 autres qualités que ne fournissent pas les autres monnaies: la dématérialisation et la non centralisation. Les plateformes d'échanges n'ont rien de nécessaires et je peux échanger avec n'importe qui au bout du monde instantanément.
Le meilleur de la monnaie scripturale (pas d'intermédiaire et son caractère anonyme et des systèmes d'échanges dématérialisé s.

Le bitcoin a des inconvénients et le plus important est l'inégalité entre les premiers mineurs et les derniers arrivés. Au fait. Si le coût du minage devient prohibitif par rapport à sa valeur, plus personne n'en produira et on se contentera d'échanger ce qui a été produit tout comme l'or à extraire. En voudra t'on a ceux qui ont mise sur l'or et décidé de le stocker en spéculant ?
Mais ça n'enlève rien a ses qualités.
Une autre cryptomonnaie émergera peut-être un jour sans ces inconvénients.
Mais décrier le minage qui fonde sa rareté sans proposer d'autres idées me parait juste de mauvaise foi.
Mais vous pouvez préférez penser que les billets verts sont plus fiables,
Les chinois seront ravis de vous refiler leurs bons du trésor contre du pétrole.

Tu le fais expres avoue.
C est exactement ce que j ai ecrit.
Relis mon post …au premier degre.
T es vraiment le specialiste pour faire dire aux autres le contraire de ce qu ils pensent.
Pour le frangliche j attends tes patchs sur le clavier francais android.