comments on draft 13

[Stefan Hepper <sthepper@hursley.ibm.com>]

Hi Rich,
here some questions that came to my mind while reading the draft 13:

1. p.15, l. 600
"In order to support bookmarking in some browsers, the Consumer may need 
to cache the navigational type of state and just supply a reference to 
it on the URL. "
I think bookmarkability will break if you cache the nav state on the 
consumer and only provide a reference to it in the URL, because at some 
point in time the cache will be cleared and then the bookmark will not 
be able to provide the same information as before. Or am I missing 
something here?

2. p. 17, l 667
"Note that the Consumer could distribute multiple events to a Portlet in 
this step (see section 6.4.2.1), including via multiple concurrent 
invocations."
Why would we need to allow concurrent invocations of the same portlet 
for the same user? This will not work for the current Java portlet 
model, as requ/resp objs are not re-entrant per user. The WSRP producer 
would need to collect these events and only forward one at a time to the 
Java portlet.


3. p 26, l 1018
"Since an event’s name can be refered to in a wildcard fashion (see 
section 5.1.17), Portlet developers are encouraged to organize their 
event’s local names hierarchically."
I think the wildcard mechanism leads towards a listener/subscribe model 
and not a service invocation model. Do we really want to go that route? 
The more I think about this the less I'm convinced that this wildcards 
are a good idea and that we should treat events more like service 
invocations. What do you think?

4. p. 40, l 1637
" In order to support items that could become part of an interaction, 
this token is required to be constant for the lifetime of the 
portletHandle and be the value used for both Consumer and Producer 
namespacing "
Why is it not session lifetime? Why a persistent lifetime? Are actions 
beyond the current session meaningful?

Stefan