See also: IRC log
Present: Umit, JMarsh, DBooth
Regrets:
Chair: dbooth
Scribe: dbooth
Umit: If you know in the pattern who is the recipient, then it's a differnent pattern than if you aren't sure whether you'll get a reply back or not.
Scribe: http://lists.w3.org/Archives/Public/public-ws-desc-meps/2003Jul/0007.html
Umit: So should we classify the patterns depending whether the initiating client knows who is the response recipient.
JMarsh: Changing the signature of the function isn't what i had in mind. Suppose there's a SOAP header for forwarding the response to someone else.
... When I'm building the stub, i need to know whether that header will be used.
... There may be other headers that will affect the MEP also.
Umit: Huge debate: What is the client interface versus what is in the stub.
... If the client knows it will get a reply back it needs to do a callback or something.
... Whether it's done by a header or something else it's still a different pattern.
JMarsh: Is looking at the pattern sufficient?'
... The combination of the IO Pattern plus the knowledge that I'm interacting in a way that can indicate a different recipient, I can no longer have all the info I need from the WSDL to build the stub.
Umit: You're only missing the address of the recipient.
JMarsh: Umit wants to look at the WSDL and know what kind of client stub to generate unambiguously.
... but there might be a variety of different stubs you may want to generate, based on other inputs.
Umit: So you're saying WSDL isn't enough to generate stubs?
dbooth: This is a very interesting question. The answer may not be the same in every case.
JMarsh: If I get a WSD with an extension, it may invalidate the existing semantics of WSDL 1.2 if required=true.
... Consider an optional extension, which Umit doesn't understand. Is there a canonical stub for it?
Umit: Assuming you understand all the WSD, you should be able (as a client) to generate stubs for them.
... There might be different bindings for them.
JMarsh: This is part of why we should open the issue for output operations.
... How do you know what is the recipient?
dbooth: That's a service issue -- not client.
JMarsh: One criterion for trimming the number of patterns is whether it's possible and convenient to build a stub for that pattern.
dbooth: All patterns seemed to be handled by the four functions summarized in http://lists.w3.org/Archives/Public/public-ws-desc-meps/2003Jul/0001.html :
Scribe: [[
... void multicastMessage(ServiceAddressList ss, Message m);
... void sendMessage(ServiceAddress s, Message m);
... Message sendAndReceiveMessage(ServiceAddress s, Message m);
... void registerMessageReceiverCallback(MessageReceiverCallback f);
... ]]
... but that's only one particular style of writing such a client library.
JMarsh: You may want to interact with the service in two ways identified by two different patterns.
dbooth: A WSD specifying p2e could have one client using it via sendAndReceiveMessage, and another client might interact with it using sendMessage and registerMessageReceiverCallback.
JMarsh: You should be able to write a variety of client stubs to interact with the WSD specifying p2e.
Umit: Given a particular pattern, client code generators should be able to infer their interaction with the service.
... Because each pattern says what they can assume.
... By looking at the WSD with p2e, the code generate will assume that there will be something sent back.
JMarsh: Umit wants to write sendAndRecieveMessage for p2e.
... Suppose WSD says p2c. Umit wants to look at the WSD and use sendAndReceiveMessage.
Umit: No. When I look at p2c, it says the response may go to a different party.
... Maybe a p2c-prime would be indicate that the response DEFINITELY goes to another party.
JMarsh: I want to do something more that what you allow. I want an operation that works in EITHER of those modes. I want the same operation to work whether the response goes back to the same party or a different party.
dbooth: So you want a WSD that specifies p2c, but to be usable by clients that want to access it via sendAndReceiveMessage or by sendMessage with registerMessageReceiverCallback.
JMarsh: Yes.
Umit: I think you want to eliminate p2e and say the p2c is more general and it's up to the client to indicate whether the reply is supposed to come back to the initiator. Right?
JMarsh: Yes.
Umit: p2c is more general than p2e, so you cannot know, only from the pattern, where the response should go.
JMarsh: If a message is sent, but the service is wiped out by a nuclear explosion and no reply is sent, is that a different pattern?
Umit: No.
JMarsh: Some people may want p2e, some may want p2c to specify a different recipient.
Umit: p2e is a very common pattern. I think it would be a problem to force them to use p2c when they know that they want the reply back.
JMarsh: But p2e is limited in what you can do with it. p2c is more general.
dbooth: Please be more specific about the examples you're using. Things get too vague and then people talk past each other.
Scribe: [Meeting adjourned]