Reprise du message précédent :

oui mais j'ai envie d'essayer la tienne
 je voulais tenter celle de InTheNavy mais y a pas de chavrou, ni de fromage de chevre d'ailleurs

annulé, trop d'alcool, pas levé, plus trop la peine de se faire le voyage pour une fin d'aprèm+soirée.

Bah, c'est clair. La seule solution, c'est vraiment d'y aller incrémentalement et de se fixer des objectifs intermédiaires.  
 
Des fois, je regarde où je souhaite arriver avec mon prog de photos, et ça me fait peur. Mais bon, j'ai un plan limite ultra-précis sur les versions et les délais, donc ça permet de mieux voir venir.

Désolé j'ai pas suivi le début, c'est quoi le problème au juste ?
 
Sinon ça vous dirait de monter un wiki culinaire ?

 
ah
 
ptain jme rapelle meme pu comment y s'appelait mon colloc   Alors que ca fait juste un an que jle vois pu

 
yeah, pis apres un bouquin "la cuisine pour les nerdz : les trucs qui peuvent se faire en glandant sur le net "

ouais
 
 deja que j'ai pas mal parse marmiton.org et artculinaire.ch (plus quelques autres sites)

supertoinette en forsse

elle etait dans les 'quelques autres sites' (mais bon, ca vaut pas marmiton )

AHAHAHAH un site sur le surf en Méditerranée  
 
C'est sur qu'en attendant les vagues elle vont avoir le temps de l'animer le site

comme dirais chris, marmiton is teh roXXorz !

cte bande de nerdz
la reflexion suit toujours le meme chemin pour moi
-j'ai faim
-j-ai ca dans le frigo
-recherche sur marmiton
-je peux me faire a manger
 

on me coupe le net, je creve de faim

connectez-moi mon modem de bourge au net !
sinon je tue le chien !
 
 
 
 
 
 
 
 
 
 
 
 
 
 
merde, c'est kadreg en personne qui va venir me couper les fil du téléphone et demander des photos /o\

 
bah ca denote un esprit scientifique :  
probleme - recherche - solution
 
je trouve ca tres bien moi
 
c'st mieux que :
-j'ai faim
-j'appelle pizza domino  
 

Bah wikipedia le fait déjà, non ?

http://en.wikibooks.org/wiki/Cookbook

immonde ce smiley

Je savais pas. Moi je pensais plus à un truc genre "la cuisine pour les nerdz", un peu entre nous .

J'vote pour Chu pas très fort en cuisine mais j'ai une bonne recette de truffes qui déchire sa race Pis j'mettrai 2-3 trucs que fait Belial, aussi

euh, tu t'emmerdes pas toi dis donc

Truffes au chocolat, gros moche

 
attends, son patron est le mieux payé de france, il est noyé dans la thune le taiche
 
au ptit dej' chez lui c'est tartine de caviar

lol

lol

 
 
Je la mets dans le blog    
 

 
Tu diras si c'est bien, d'accord ?    
 

 
La propriété c'est le mal    

 
Elle est dans le domaine public maintenant
 

 
Rien n'échappe au chevalier du vernis à ongles pailleté
 

 
C'est bon aussi avec de la ricotta, ou bêtement du fromage blanc, en fait (mais là j'ajouterais des oignons émincés et fondus au beurre mais pas trop)
 
 
 

 
Saucisse ? Poulette ? Nounouche ?  
 

 
Va falloir trouver un illustrateur    
 

 
Ah ben oui    
 

 
 
Ou bien tu ouvres un resto ?

 
oué, mais ca nous dira pas si c'est pas bon ou si c'est moi qui ait tout fait de travers
 

 
Non jviens de me rapeller, c'etait christian
jsuppose qu'a l'heure actuelle il doit jouer a diablo II sur son pécé

putain le nouveau smiley à la mode

bon, interro surprise : parlez-moi des transactions de compensation. 10 lignes, un quart d'heure.

 
 
J'ai confiance, en fait
 
Je crois que je connais quelqu'un qui joue à Diablo moi aussi

putain mais il neige à fond là

 
 
Transactional Conversations
Svend Frolund and Kannan Govindarajan
Hewlett-Packard Company
email: svend_frolund@hp.com, kannan_govindarajan@hp.com
Introduction  
We believe that web services should make their transactional properties available to other web services in an explicit and standard way. Transactional properties should be part of a service's interface rather than a hidden aspect of its backend. The transactional behavior of a service can then be exploited by other services to simplify their error-handling logic and to make entire business-to-business interactions transactional. However, such business-to-business transactions are challenging to implement because they span multiple companies and because the underlying transaction protocols execute over wide-area networks.
 
It is fundamental for web services to communicate through conversations. A conversation is a potentially long-running sequence of interactions (document exchanges) between multiple web services. For example, a manufacturer may engage in a conversation with a supplier and a conversation with a shipper to carry out the activity of purchasing parts. In many situations, the backend logic triggered as part of these conversations may be transactional. For example, it may be possible to arrange for parts to be shipped, and then later cancel the shipment (if the parts have not actually been sent yet). Cancelling the shipment is an example of a compensating transaction, it compensates for the initial transaction that arranged the shipment. Since the notion of conversation is fundamental to web services, the exportation of transactional properties should fit with conversations, giving rise to transactional conversations.  
 
In the Internet setting, atomicity is the most important aspect of transactions. Atomicity means that the effect of a transaction either happens entirely or not at all. We also refer to this as all-or-nothing semantics. If a service A knows that a conversation with another service B is atomic, then A can cancel the conversation and know that B will cleanly revert back to a consistent state. Furthermore, A can rely on the B's transactional behavior to ensure state consistency in the presence of failures, such as logical error conditions (e.g., shipping is impossible) or system-level failures (e.g., the crash of a process or machine).  
 
Services should expose their transactional behavior in a manner that facilitates composition of transactions from different services. For example, it should be possible for the manufacturer to compose a transactional conversation with the supplier and a transactional conversation with a shipper into a transactional activity that includes both conversations. The advantage of creating these multi-conversation transactions is that the manufacturer gets all-or-nothing semantics for the entire end-to-end purchasing activity: if shipping is not available, the order placement is cancelled. This is a very powerful notion, that we believe will significantly reduce the complexity of programming business-to-business activities between multiple web services. Composite transactions provide a notion of "clean abort" for entire business-to-business activities. Moreover, having a standard notion of transaction allows us to build generic software components that perform the transaction composition.  
 
Atomicity
We discuss different ways for transactions to be atomic. As terminology, we introduce the notion of a transaction outcome, which is either commit or abort. The outcome is abort if the effect of the transaction is "nothing." The outcome is commit if the effect is "all."  
 
Two-Phase Commit and Compensation
If we execute two atomic transactions, their combined effect is not necessarily atomic: one transaction may abort and the other may commit, which means that the combined effect is neither all nor nothing. If we create a composite transaction from two constituent transactions, we need to ensure that either both constituent transactions commit or that both constituent transactions abort. There are two traditional ways to ensure this. One way, called two-phase commit, is based on the idea that no constituent transaction is allowed to commit unless they are all able to commit. Another way, called compensation, is based on the idea that a constituent transaction is always allowed to commit, but its effect can be cancelled after it has committed.  
 
With two-phase commit, transactions provide a control interface that allows a transaction coordinator to ensure atomicity. One incarnation of the control interface is the XA specification [3]. Essentially, the control interface provides a prepare method, an abort method, and a commit method. The coordinator calls the prepare method to determine if a transaction is able to commit. If the transaction answers "yes," then the transaction must be able to commit even if failures occur. That is, the transaction is not allowed to later change its mind. If all transactions answer "yes," the coordinator calls their commit method, otherwise the coordinator calls their abort method.  
 
With compensation, there is no additional control interface. Instead each "real" transaction has an associated compensating transaction. With compensation, a coordinator can ensure atomicity for a number of constituent transactions by executing the transactions, and if any transaction aborts, the coordinator executes the compensating transaction for all the transactions that have committed.  
 
Discussion
Although both two-phase commit and compensation can provide atomicity for composite transactions there are trade-offs between the two methods. Compensation is optimistic in the sense that the coordinator only enters the picture if something bad (e.g, abort) happens. With two-phase commit, the coordinator enters the picture even if all transactions commit. The coordinator always calls prepare and either commit or abort for any transaction. On the other hand, two-phase commit always provides a point after which a service can forget about a transaction. Once the transaction is instructed to commit, the service can forget about the transaction. With compensation the service has to be able to compensate forever. The ability to compensate may or may not require the service to maintain persistent state. Of course, there are hybrid models where compensation is bounded by time or the occurrence of events (such as receiving a notification).
 
In practice, few systems use two-phase commit in the Internet context. One reason is that, with two-phase commit, a service exposes transaction control to other services. If a service answers "yes" in response to a prepare request, the service has to be able to commit the transaction until instructed otherwise by the coordinator (which may be another service). Few services are willing to export such transaction control in a loosely-coupled system. Another reason for the limited use of two-phase commit is that composite transactions may be long running. If we want transactions to span entire business-to-business activities, we have to accept the possibility that transactions may run for a long time. With two-phase commit, a constituent transaction cannot commit until the composite transaction can commit. Thus, a fast service may be forced to wait for a slow service.  
 
If we want to support two-phase commit, we need a protocol that allows flexible designation of the coordinator role. For example, a given web service may be willing to play the role of participant in certain situations, but may insist on playing the role of coordinator in other situations. If we have a conversation definition language, such as CDL [1], we can capture this distinction through different conversations. A service can export a coordinator version and a participant version of the same logical conversation.  
 
We believe compensation is a fundamental notion of atomicity for web service, and in the remainder of this paper, we shall only consider compensation. This does not reflect a position against two-phase commit, but is merely to simplify the discussion.  
 
Isolation, Durability, and Consistency
Traditional database transactions satisfy the ACID properties (atomicity, consistency, isolation, and durability) [2]. Unlike traditional database transactions, we do not believe that transactions, in the context of conversations, should necessarily provide isolation. Isolation is concerned with controlling the concurrent execution of transactions to provide the illusion that concurrent transactions execute one after the other in some (indeterminate) serial order. Isolation is unnecessarily strict for Internet transactions. This is evident from many Internet sites that provide transactions without isolation. For example, sites, such as Amazon.com, provide transactional semantics in the form of compensation (cancelling an order within a given time limit) and do not provide isolation. Besides being unnecessarily strict in many cases, isolation is also costly because transactions may be long running, and providing isolation for long-running transactions hampers the overall performance.
 
To continue the comparison with database transactions, we would expect the "primitive," constituent transactions to provide durability and consistency. Durability means that transactional updates are made persistent if the transaction completes successfully. Consistency means that a transaction takes the system from one consistent state to another. The durability and consistency of constituent transactions follows from the transactional properties of the backend logic in web services. We do not believe that "composite," multi-conversation transactions should provide any global notions of durability or consistency beyond what the constituent primitive transactions provide. In other words, we do not rely on any particular notion of durability or consistency when we compose primitive transactions into composite transactions.
 
Describing Transactional Properties
We outline briefly what it may take to describe, and thus export, transactional properties of web services. The starting point for our discussion is the assumption that services communicate through explicit conversations. If a service exports a description of its conversations--the conversations it is willing to engage in--the question is how the service can specify the transactional properties of those conversations. The specification makes explicit to other services how the service is transactional. The specification should communicate the following aspects of transactions:
 
Demarcation . We need to describe which parts of a conversation are transactional. If we consider a conversation as a sequence of interactions, we need to identify the transactional sub-sequences of those interactions. At one extreme, the entire conversation may be transactional. But other possibilities may exist as well. For example, only a single interaction may be transactional, or an identified sub-sequence may be transactional. In general, a single conversation may have multiple transactional parts.  
Outcome. To exploit the transactional behavior of a service, we need to know the outcome (commit or abort) of its transactions. One way to communicate the outcome of a transactional conversation to other services is to associate a particular outcome with a particular point in the conversation. For example, a specific interaction may denote abort and another interaction may denote commit. If the conversation reaches an interaction that indicates abort, the parties of the conversation know that the outcome is abort. We need to describe which interactions indicate abort and which interactions indicate commit. Notice that we can also use document types instead of interactions to indicate the outcome of transactions.  
Compensation. We need to describe how transactions can be cancelled or compensated for. For example, a conversation may have a particular document that triggers compensation, or different documents may trigger compensation at different points in the conversation. To initiate compensation at a given point in a conversation, sending a compensation document must be a legal interaction at that point in the conversation, and we must be able to generate the appropriate compensation document. Notice that compensation may not be possible at any point during a transactional conversation, so we need to know both how and when compensation is possible.  
If a service exports a description of its conversations in the form of an XML document, we can think of the description of the transactional properties as a companion document.  
 
Requirements
To conclude, we outline basic requirements for web service transactions.
 
We want our notion of web service transaction to fit with conversations. Conversations provide the context for transactions: transactions take place within conversations, and we talk about transactional conversations. The integration of conversations and transactions have consequences for the transaction model. Because conversations can be long-running, so can transactions. The transaction protocols, such as two-phase commit and compensation, involve communication between web services. These communications should be first-class members of the conversations between web services. For example, if we have a conversation definition language to describe conversations, we should use that language to describe the transaction protocols as well.
 
We want to support compensation as part of the transaction model. With two-phase commit, transactional web services rely on an external entity, a transaction coordinator, to communicate the transaction outcome to them. Such reliance on external entities may not always be appropriate in loosely-coupled systems. Compensation does not introduce the same level of reliance on external entities. Our position is not against two-phase commit, but rather in favor of compensation: two-phase commit protocols may be appropriate in certain situations. If we have a transaction model that supports both two-phase commit and compensation, we have to address the issue of "mixed-mode" transactions--transactions whose constituent transactions are based partly on two-phase commit and partly on compensation.  
 
In general, regardless of the choice of transaction model, we want to support a decentralized, peer-to-peer model for transactions. For example, we do not want to assume the existence of a centralized transaction coordinator. We do not want to prevent a centralized notion of coordinator, we simply do not want to rely on one. Notice that the notion of a transaction coordinator may be relevant for both two-phase commit and compensation. A central coordinator might make sense in conjunction with compensation. This coordinator would then gather the outcomes of the various constituent transactions and execute compensation transactions as necessary.
 
We need to address the issue of trust between the web services that participate in a transaction. Both two-phase commit and compensation assumes that the various parties are well-behaved (or trusted). For example, two-phase commit assumes that participants vote "honestly" and that they do as instructed (commit or abort). Furthermore, the notion of compensation also assumes that a participant actually executes a compensating action if instructed to do so. With two-phase commit, each participant also trusts the coordinator to be in control of the protocol--the protocol is inherently asymmetric because the coordinator knows the outcome before any of the participants. Since trust is a general issue for web services, we assume that some other mechanisms are put in place to deal with trust in a general sense. In terms of transactions, we need to integrate with those general mechanisms to handle trust. It is unlikely that we can treat trust as a completely orthogonal issue to transactions.
 
References
[1] K. Govindarajan, A. Karp, H. Kuno, D. Beringer, and A. Banerji, "Conversation Definitions: defining interfaces of web services," submitted to the 2001 W3C workshop on web services.
 
[2] J. Gray and A. Reuter, "Transaction Processing: concepts and techniques," Morgan Kaufman Publishers, 1993.
 
[3] Distributed Transaction Processing: The XA Specification, X/Open Snapshot, 1991.
 

sans google

je tape vite en anglais hein  
 
nan mais allé je vous dit l'astuce... j'ai un qwerty  

 
à toulouse?!  

Tu t'es vachement amélioré, c'est clair.  
You have very much improved yourself, it's clear.

 
c'est quoi la "copensation" ?  
 
et oui il neige à Toulouse, je viens pour une semaine et il neige

ben c'est grace à toi Lams..  
 
edit: d'ailleurs encore merci pour tout..