Re: [wsrp-wsia] Minutes for 06 March 2003 Meeting

[Michael Freedman <Michael.Freedman@oracle.com>]

Rich,
   Are you suggesting we defer the discussion of updating the portlet 
API to support access/retrieval of resources or are you also suggesting 
we defer the discussion of modifying the existing proxy resource 
mechanism to allow user context/cookies to be passed when the resource 
is invoked?  I hope its not the later as JSR 168 needs such function -- 
and asking that the information be carried on the URL itself suffers not 
only from the privacy/exposure issue but also from the long URL issue.
     -Mike-

Rich Thompson wrote:

>Thanks Andre for putting together this proposal on how an operation could 
>be defined to deal with this request for passing data to resources. It 
>helped to crystalize why I have been feeling uneasy with this discussion.
>
>When we first began discussing resources (I think that was April-May 
>2002), we quickly separated them into two camps:
>
> 1. Simple resources (e.g. a gif). A portlet's markup is likely to want to 
>reference such items as they often can not be incorporated inline. We 
>decided to encourage these to be absolute URLs, but also added the 
>proxying of resources to v1 in order to handle the case where the user 
>agent is unable to access the resource directly.
>
> 2. Complex resources (eg. a jsp page). Inclusion of these types of 
>resources is paramount to dynamically constructing the page layout under 
>the portlet's control (i.e. the portlet is saying how to directly 
>aggregate subcomponents into its portion of the page). While we did not 
>want to rule out doing such aggregation, it was deferred out of v1 with 
>the view that the portlet could always directly aggregate such resources 
>itself before streaming the aggregated markup tothe Consumer.
>
>I think the discussion of how to pass various pieces of data to a resource 
>definitely falls into #2. I understand the very fuzzy line between these 
>two as the Portlet can always pass data to more complex resources via the 
>URL (or possibly cookies), but am concerned that we can not reasonable 
>work through the issues and architect this whole area without delaying v1. 
>I think our earlier decision was right and therefore would prefer the 
>entire discussion move into a 1.1 timeframe.
>
>Rich Thompson
>
>
>
>
>Andre Kramer <andre.kramer@eu.citrix.com>
>03/07/2003 10:03 AM
> 
>        To:     WSRP <wsrp-wsia@lists.oasis-open.org>
>        cc: 
>        Subject:        RE: [wsrp-wsia] Minutes for 06 March 2003 Meeting
>
>
>On yesterdays call I took the action to draft a strawman proposal for how
>resources can be accessed within a producer / consumer context without
>re-inventing a HTTP encoding of our protocol. As Eilon previously 
>suggested
>with much foresight, this introduces a new candidate operation in our 
>markup
>interface and suggests a new url type. I wanted to get a strawman out 
>before
>the weekend, so that people can reflect on such an approach. Basically, 
>the
>resource becomes "owned" by a (producer offered) portlet who supplies it's
>portlet description, so that most of our protocol machinery can be 
>re-used.
>
>
>But firstly, the current resource URL type should not go away or change. 
>It
>is very useful for light-weight static state-less REST
>(http://www.w3.org/TR/webarch/) resources that can be readily cached at 
>the
>http level.
>
>We may even like to let resource http requests have cookies (though
>personally I think this is not required, if we accept this strawman and as
>the Web does not mandate cookies) or forward POSTs (again a consumer may
>want to not support this: I, as a consumer, don't want a producer to say
>POST some form from a script to "transfer money from my account" to some 
>URL
>(the bank's and include my banking cookies). I know consumers will do 
>access
>control (I hope :-) on resource URLs, but it still seems a dangerous
>feature. And what about honouring re-directs - that could keep a server
>busy?)
>
>
>Especially, I do not think we should make sure our session cookie is valid
>(initCookie and InvalidCookie fault requirements) for HTTP resource
>requests, or try to add our data (UserProfile etc) to Web requests, or 
>even
>make sure this data can be referenced from HTTP requests.
>
>But I agree we do need to support this functionality, as a consumer (not 
>the
>Web user agent client) should be able to interact with a resource that is 
>a
>part of a larger producer side "Web Application". Functionality included
>here is structured form data (via attachments in future), established
>security context etc. This does not imply that the access need be direct 
>to
>the (Web) resource, rather it should go via the same application access
>control and share its context with portlet requests, i.e. our SOAP
>super-layer. This may then forward the request to a J2EE Servlet, a 
>ASP.NET
>Web Form, or even serve up the resource directly from the producer side
>Portlet/Web application/server context.
>
>One could argue that a Portlet (in getMarkup and
>perform(Non-Blocking)Interaction for POSTs) can already do this. The new
>operation simply allows the Producer container (apologies to those who 
>have
>no such thing;- a library not a container is implied)  to do it more
>automatically.
>
>
>I am going to propose to name the operation "getPortletResource" and the 
>url
>type "portletResouce" (keeping "resource" urls as is and to help flag that
>this operation is in the portlet application scope. We can argue we have 
>no
>such thing as application scope; I just mean groupID and other metadata),
>but strictly the new operation is derived from
>perform(NonBlocking)Interaction, so really should be called some thing 
>like
>"performPortletResourceInteraction".
>
>The new url type (wsrp-urlType=portletResource) MUST carry the wsrp-url
>parameter (more a uri than a url here) and MAY include a wsrp-secureURL
>boolean (default is false). wsrp-fragmentID can be easily encoded on the
>wsrp-url and I would like to make resource re-writing dynamic, so no
>wsrp-rewriteResource for this url type. portletResource MUST also specify 
>a
>wsrp-owningPortlet parameter (containing a portlet handle which should
>really be for a producer offered portlet) IF the call is to be in a http
>session or if a user context (profile data) is to be communicated. We may
>also like to add a wsrp-supplyUserContext boolean parameter (usual use 
>case
>is true).
>
>For a portletResource url in a Portlet's markup we can let the
>current/"this" portlet be the wsrp-owningPortlet. We may even make this
>implicit. I think it's nicer to make it an explicit parameter for
>portletResource urls. Note, this does not change what follows the next
>paragraph.
>
>Also note that, for re-writing, the markup returned should not really
>contain any of the following wsrp-urlTypes: action, blockingAction and
>render. For complete re-writing of http resources the consumer must
>currently encode the portlet instance into the url returned to the client.
>That could be the wsrp-owningPortlet but, for now, we should encourage use
>of render urls in favour of portletResource urls, if the generated markup 
>is
>portlet specific. For 2.0 & Events, we may want to allow arbitrary portles
>to be url targets in any markup.
>
>
>Finally (thanks for your patience with the above), we come to the 
>operation
>description itself. The (possibly implicit) wsp-owningPortlet url 
>parameter
>is used to make sure a http session is in place, by directing the consumer
>to look at the owningPortlet's portletDescription's groupID (if
>serviceDescription.requiresInitCookie is "perGroup"). This should not
>require a call to getPortletDescription if the owningPortlet is a producer
>offered portlet and the producer service description is cached. The 
>consumer
>will want to also look at the portletDescription's markupTypes[],
>userCategories, userProfileItems, usesMethodGet meta data (no other fields
>are relevant here). [Having to ignore the MarkupType's windowStates and
>modes is a bit ugly.]
>
>The new section 6 markup operation:
>
>
>ResourceContext = getPortletResource(RegistrationContext, UserContext,
>ResourceParams, url);
>faults: Security.AccessDenied, Security.InvalidRegistration, 
>          Interface.MissingParameters, Interface.OperationFailed,
>Interface.InvalidUserCategory,
>          Interface.InvalidCookie, Interface.UnsupportedLocale,
>Interface.UnsupportedMarkupType
> 
>
>IN arguments for getPortletResource:
>
>RegistrationContext registrationContext: optional registration context. It
>is up to the consumer to guess the registration requirements and track any
>resulting scope.
>
>UserContext userContext: The consumer can not assume this is stored in a
>session and MUST supply a userContext if the url carried a (possibly
>implicit) wsrp-supplyUserContext==true parameter. [Only the userContextKey
>is actually Required.] The user profile is to be constructed using the
>normal portletDescription.userProfileItems rules.
>
>ResourceParams resourceParams (restiction of MarkupParams and 
>RuntimeContext
>)  {
>
>                 [R] boolean secureClientCommunication;
>                 [R] ClientData clientData;
>                 [R] string userAuthentication;
> 
>                 [O] NamedString formParameters[];
>                 [O] UploadContext uploadContexts[];
> 
>                 [R] string locale[];
>                 [R] string markupType[];
>                 [O] string markupCharacterSet[];
>
>                 [O] string namespacePrefix; // may not be used if return
>requiresUrlRewriting==true
>                 [O] string validateTag;
>                 [O] Extension extensions[];
>}
>
>String url/uri: the wsrp-url parameter value. [could be in
>ResourceParameters but I wanted to call it out. Encodes interactionState].
>
>
>RETURN(OUT) parameter: may be null (if ResourceParams.formParameters != 
>null
>or uploadContexts != null)
>
>ResourceContext resourceContext (restriction of MarkupContext) {
>                 [O] boolean useCachedMarkup;  // sort of an [R] as it has 
>a default
>"false"
>
>                 [O] string markupType;          // future: attachments 
>could return multiple
>results
>                 [O] string markupString;
>                 [O] base64binary markupBinary;
>                 [O] string locale;
>
>                 [O] boolean requiresUrlRewriting;
>                 [O] CacheControl cacheControl; // here our defined 
>caching semantics
>may even be useful!
>                 [O] Extension extensions[];
>}
>[only blocking portlet interactions can do redirects & change nav state.
>Could be MarkupContext is we ignore the optional preferredTitle and don't
>add anything else.]
>
>Finally, note that this operation would be optional for producers as only
>they write portletResource URLs.
>
>regards,
>Andre
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
>  
>



----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>