Section 6 uploaded

[Rex Brooks <rexb@starbourne.com>]

Hi Folks,

This may be a repeat of the same message I am using with the upload 
in the Kavi system online.

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
-- 
Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com
Tel: 510-849-2309
Fax: By Request