IRC log of ws-ra on 2009-01-16

Timestamps are in UTC.

00:02:15 [wu]
gil: as event sink, may need more detail, e.g. SOAP 1.1, 1.2, RPC, ...
00:04:17 [wu]
gil: static wsdl is hard to determine the what binding is.
00:04:42 [wu]
Yeves: binding maybe specified in subscription time to make things easy
00:05:46 [wu]
bob: 6429 will take further discussion to the list.
00:06:14 [wu]
bob: 6430
00:07:55 [gpilz]
??P5 is a trouble maker
00:08:12 [gpilz]
see, told you
00:08:22 [dug]
00:08:25 [wu]
li: propose an attribute to indicate event source
00:08:29 [gpilz]
00:08:54 [wu]
li: we should consider W3C Semantic Annotation for WSDL and XML Schema
00:09:19 [asir]
00:09:56 [Bob]
ack dug
00:11:57 [wu]
dug: I am wondering if this should be at portType level, operation level, etc.
00:12:30 [Bob]
ack gpil
00:13:28 [wu]
gil: need to do homework and think of a competing proposal using policy
00:16:40 [Bob]
ack asir
00:17:21 [wu]
prasad: this may relate to bp issue
00:18:33 [wu]
asir: some question of attribute
00:19:04 [wu]
li: it allows to you to subscribe port, not source
00:19:23 [wu]
asir: it will help to make the context know.
00:20:27 [wu]
li: in ecma-348, need to indicate in SOAP header
00:20:50 [wu]
Geoff: what is the mapping in wsdl and what you subscribe
00:21:12 [wu]
li: this is another submitted issue for ws-e
00:22:01 [wu]
asir: some background of the issue is very helpful
00:23:46 [wu]
asir: policy assertion apply to shared behavour and event source may not
00:23:55 [Bob]
action: Li in email to the public list, describe the background and implications to 6430 more fully
00:24:13 [Bob]
rrsagent, pointer
00:24:13 [RRSAgent]
00:24:31 [wu]
Geoff: to link the issue with 6425 which is another half will be helpful
00:25:52 [wu]
bob: 6431 is next
00:26:21 [wu]
li: propose add pause/resume operation to ws-e
00:27:26 [Bob]
rrsagent, pointer
00:27:26 [RRSAgent]
00:27:38 [wu]
li: it can reduce ws-e overhead in subscribe/resubcribe
00:27:54 [wu]
gil: seem a good idea, like to see more detail
00:28:43 [wu]
bob: events will be qued or pause event delivery
00:29:32 [wu]
li: open to implementation/application at this moment
00:30:36 [wu]
gil: maybe define pause or queue at start. maybe this is an implementation choice
00:30:54 [asir]
00:31:28 [wu]
bob: it may add a lot of complexity. there is any additional cost beyond subscribe/unscribe
00:32:11 [wu]
00:32:58 [Prasad]
What if you pause and forget (to resume) forevere?
00:33:20 [Prasad]
00:33:22 [wu]
li: pause is very common in business case
00:34:07 [Prasad]
00:34:08 [Bob]
ack asir
00:34:29 [wu]
asir: need to consider cr phase
00:34:31 [Yves]
questions about possible cost of a subscription or delivery reminds me of the safeness of WS-Transfer:Get...
00:34:54 [dug]
Yves - can you elaborate?
00:35:18 [Bob]
ack wu
00:35:23 [Yves]
if you retreive something using WS-T:Get and something goes wrong, is it safe to re-issue the request or not?
00:35:56 [Yves]
ie: is WS-T:Get used in case of payment to retreive information (where you don't want to do twice ;) )
00:35:58 [asir]
00:36:01 [Bob]
ack prasad
00:36:29 [Yves]
we might clarify that in WS-T then
00:36:37 [Yves]
I'll open an issue ;)
00:36:42 [wu]
wu: we can confine pause as a short-hand of subscribe/unsubscribe then subscribe, which semantics are defined in ws-e
00:36:43 [asir]
00:38:34 [Zakim]
- +1.908.696.aaaa
00:38:39 [dug]
are you saying that T.get() will change the fact that a payment happened?
00:39:50 [Prasad]
If we introduce pause / resumeetc, semantics need to be simple. No pooling of events until resume etc. Pause will make you lose events until resume also. Otherwise huge overhead on the event-source side and what if the pause is never resumed. There need to be timeout semantics also
00:39:59 [Yves]
no, I just wonder if people are tying T.Get and payment (as it may lead to double charging someone if T.Get implies you can safely re-issue the request if something fail, like power failure)
00:40:32 [wu]
bob: 6398 issue
00:41:43 [Geoff]
00:43:41 [Bob]
ack geo
00:43:47 [wu]
dug: looking atthe impact on ws-rt
00:45:59 [wu]
Geoff: we need extensibility. ws-rt spec is on extending ws-t.
00:46:36 [wu]
Geoff: by making changes suggested, this relation broken
00:47:10 [wu]
Geoff: Thus, this is a significant change to ws-rt
00:47:51 [wu]
asir: needs to think more
00:48:27 [wu]
dug: one way to solve it is to ask ws-rt to use the same wrapper
00:48:47 [wu]
asir: this is significant change and like to see detail
00:48:54 [gpilz]
gpilz has left #ws-ra
00:49:21 [asir]
00:49:32 [wu]
dug: like to know if this wg is o.k. to that geneal direction
00:50:07 [Bob]
ack asir
00:50:57 [wu]
asir: need to know more if this is reasonable
00:53:56 [Bob]
action: Dug Take proposal for 6398 to the next level of detail including extension to include impact on WS-RT, including deleteRequest (getting us to 8 operations in T)
00:55:18 [asir]
s/T)/T) and MEX
00:55:39 [gregcarp]
00:55:54 [Bob]
ack greg
00:57:02 [Zakim]
00:57:03 [Bob]
rrsagent, generate minutes
00:57:03 [RRSAgent]
I have made the request to generate Bob
00:57:30 [wu]
see you next Tuesday
00:59:09 [Zakim]
00:59:10 [Zakim]
WS_WSRA()11:00AM has ended
00:59:11 [Zakim]
Attendees were +1.908.696.aaaa, gregcarp