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]
- +q
- 00:08:25 [wu]
- li: propose an attribute to indicate event source
- 00:08:29 [gpilz]
- +q
- 00:08:54 [wu]
- li: we should consider W3C Semantic Annotation for WSDL and XML Schema
- 00:09:19 [asir]
- q+
- 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]
- See http://www.w3.org/2009/01/16-ws-ra-irc#T00-24-13
- 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]
- See http://www.w3.org/2009/01/16-ws-ra-irc#T00-27-26
- 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]
- q+
- 00:31:28 [wu]
- bob: it may add a lot of complexity. there is any additional cost beyond subscribe/unscribe
- 00:32:11 [wu]
- q+
- 00:32:58 [Prasad]
- What if you pause and forget (to resume) forevere?
- 00:33:20 [Prasad]
- s/vere/ever/
- 00:33:22 [wu]
- li: pause is very common in business case
- 00:34:07 [Prasad]
- q+
- 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]
- safe
- 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]
- ok
- 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]
- q+
- 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]
- q+
- 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]
- q+
- 00:55:54 [Bob]
- ack greg
- 00:57:02 [Zakim]
- -gregcarp
- 00:57:03 [Bob]
- rrsagent, generate minutes
- 00:57:03 [RRSAgent]
- I have made the request to generate http://www.w3.org/2009/01/16-ws-ra-minutes.html Bob
- 00:57:30 [wu]
- see you next Tuesday
- 00:59:09 [Zakim]
- -??P5
- 00:59:10 [Zakim]
- WS_WSRA()11:00AM has ended
- 00:59:11 [Zakim]
- Attendees were +1.908.696.aaaa, gregcarp