Groups - wsrp-primer-1.0-draft-0.5-Section-6-pt1.doc uploaded

[rexb@starbourne.com]

The document wsrp-primer-1.0-draft-0.5-Section-6-pt1.doc has been submitted by Rex Brooks (rexb@starbourne.com) to the WSRP Primer SC document repository.

Document Description:
I have uploaded my latest work on Section 6 using Subbu's changes up through 6.5 Interaction Operations, where I just gave up for this weekend.  I wanted to get this to you so you could include it in the next version you post, Subbu, by cutting and pasting the new parts of Section 6, which is largely reworked.

I have been having a consistent non-stop set of techological problems with my email and my computers, which may be related, but working through all the trouble shooting would bore you to tears, and only makes me more aggravated. I am picking away at it and will probably have to continue to do so piecemeal as I also try to get as much actual work done as I can while I plug along. It's utterly maddening, but I can't afford to take as much time as it would take to simply keep troubleshooting until I get all the gremlins sorted out.

Unfortunately, not all of the gremlins are on my side, and there is precious little I can do about my domain hosting server.

Anyway, on to more germane thoughts.

I agree that the old Message 14 is not needed, but that caused me to think: How do we show a  plain vanilla getMarkupResponse that is simply ready to be displayed as is, instead of requiring user authentication with the producer? As it is now, though an improvement, has the first getMarkupResponse requiring a 'wsrp rewrite?wsrp-urlType-blockikingAction...' 

Starting off with an example that requires a 'blocking' action seems confusing to me, and doesn't start with the simplest case, which would be the (assumed) existing portlet for the User, with the User being or having been authenticated by the Consumer with an appropriate userContext included in the messages that tracks the P Inc. - C Inc. example.  I don't think we need to show the user authentication of this portlet, just this particular session with its sessionID and navigationalState. Then we can have the performBlockingInteraction() come about as a request to add a new stock symbol. And this ought to be secureCommunicationChannel="true" for the new request.  Could we do it that way? Then we could actually SHOW navigationalState being propagated, and show that the Consumer has set the portletStateChange flag to 'readWrite' and make this whole section hold together better.  That also makes what constitutes the persistent state change more clear. It might also be wise to explain or show the messages for an update of a mutual fund portlet on the same page from the same producer  while the performBlockingInteraction is taking place at the same time, although I could cite that instead of having the message.  Anyway, let me know how this works out, and I will try to get the rest of Section 6 done after I hear from you and we decide how we want to finish this section up. I would like to have it done before our next meeting.  Ciao, Rex 


Download Document:  
http://www.oasis-open.org/apps/org/workgroup/wsrp-primer/download.php/6449/wsrp-primer-1.0-draft-0.5-Section-6-pt1.doc

View Document Details:
http://www.oasis-open.org/apps/org/workgroup/wsrp-primer/document.php?document_id=6449


PLEASE NOTE:  If the above links do not work for you, your email application
may be breaking the link into two pieces.  You may be able to copy and paste
the entire link address into the address field of your web browser.