OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wsrp] [CR308] - Add requestMethod field to MarkupParams


Title: RE: [wsrp] [CR308] - Add requestMethod field to MarkupParams

I remember this being discussed for 1.0 (having brought it up). I abandoned it then as:

1) a consumer to user agent / client protocol (if any) may not even be HTTP based.

2) a consumer should be free to re-write "URLs" (see 1) as it likes (even switching method).

(d) would also significantly lessen any value of this field ...

Regards,
Andre

-----Original Message-----
From: Subbu Allamaraju [mailto:subbu@bea.com]
Sent: 01 November 2004 14:57
To: wsrp@lists.oasis-open.org
Subject: Re: [wsrp] [CR308] - Add requestMethod field to MarkupParams

Here is another attempt to justify the need for this field. I'm assuming
J2EE environment here, but the same must be true for others.

a. One of the possible implementations of a Producer is a portlet
container which creates a runtime for portlets. The runtime includes
request and response objects (e.g. HttpServletRequest, and
HttpServletResponse) among other things. Currently, except for the
method used, it is possible to provide usable request and response
objects to portlets.

b. It should be easy to use third party code (such as servlets, JSPs,
tag libraries etc) in portlets. For example, if a third-party JSP tag
library relies on the request method to do something special, it should
not break or misbehave when it is deployed in a producer runtime.

c. The proxy example is non-trivial. However, instead of relying on a
getMethod()-like method, the portlet will have to take some extra steps.

d. Making this field optional would address cost considerations.

Finally, it is difficult to explain web developers why the Producer
runtime cannot provide a dependable getMethod, because, for portlet
developers, the Producer runtime is (should be) no different from a
typical web container.

Subbu

Rich Thompson wrote:
>
> The reason I am raising the questions is that I understand the cost of
> adding such a field (Consumer has to serialize another piece of
> information into each getMarkup message), but still don't really
> understand the value.
>
> Presume there is a portlet that can act as a proxy for a number of
> resources (urls). Lets consider the explicit case where its current
> markup contains links of some form that allow the user to navigate to
> one of these proxied resources. In order to write those links into the
> markup, the portlet had to know enough about the resource to collect any
> required parameters, etc and devise a scheme by which that information
> will flow back to the portlet. This could be done either directly (i.e.
> pushed onto the link, perhaps using a form if the user is to enter some
> part of the data) or indirectly (i.e. a reference to info the portlet is
> storing is pushed onto the link). It seems to me that the nature of how
> the resource is fetched is only one piece of the info the portlet has to
> have in order to proxy things properly. I also don't see that there is
> necessarily a direct relationship between how the portlet get the info
> it needs to communicate with the resource and how it must pass that info
> to the resource. As a result, I am not understanding the value such a
> field would bring.
>
> Rich
>
>
> *Subbu Allamaraju <subbu@bea.com>*
>
> 10/22/2004 09:52 AM
>
>      
> To
>       wsrp@lists.oasis-open.org
> cc
>      
> Subject
>       Re: [wsrp] [CR308] - Add requestMethod field to MarkupParams
>
>
>      
>
>
>
>
>
> Some primary considerations for adding this filed:
>
> a. Although not common enough, this field would make it easy for web
> developers to write portlets without learning about the complexities.
>
> b. Producer implementations don't necessarily parse the entire markup
> being generated (except for links and IDs). Without parsing the markup
> Producers cannot embed the request type into links. Parsing the markup
> just for the sake of embedding the request type may not be efficient.
>
> Is there a strong reason against including such a field? This field
> seems very harmless to me.
>
> Subbu
>
> Rich Thompson wrote:
>  >
>  > My primary question is whether it is a common enough use case to require
>  > the Consumer to provide the field on every getMarkup message to every
>  > portlet. My first thought is that it does not rise to that level and
>  > that it is easy enough for a portlet to provide such proxying when it
>  > wants to. It also is not difficult for a platform that wants to
>  > automatically make such info available to the portlets it hosts to add
>  > and remove an indicator from the navState.
>  >
>  > As an aside, should the Primer capture the issues involved with trying
>  > to use a post with a render url? Things such as submitted forms are
>  > likely to be lost as they don't translate into anywhere on the getMarkup
>  > message.
>  >
>  > Rich
>  >
>  >
>  > *Subbu Allamaraju <subbu@bea.com>*
>  >
>  > 10/19/2004 01:28 PM
>  >
>  >                 
>  > To
>  >                  Rich Thompson/Watson/IBM@IBMUS
>  > cc
>  >                  wsrp@lists.oasis-open.org
>  > Subject
>  >                  Re: [wsrp] [CR308] - Add requestMethod field to
> MarkupParams
>  >
>  >
>  >                 
>  >
>  >
>  >
>  >
>  >
>  > That is the work-around with WSRP1.0. Any reason against adding such a
>  > field? It would make it easy for web developers.
>  >
>  > Subbu
>  >
>  > Rich Thompson wrote:
>  >  >
>  >  > Do we really need this field? The portlet has to already know this to
>  >  > have coded the URL to use the right method. It can easily use that
>  >  > knowledge (possibly by passing it to itself in navState) if it is
>  >  > actually proxying the markup from somewhere else.
>  >  >
>  >  > Rich
>  >  >
>  >  >
>  >  > *Rich Thompson/Watson/IBM@IBMUS*
>  >  >
>  >  > 10/19/2004 09:00 AM
>  >  >
>  >  >                 
>  >  > To
>  >  >                  wsrp@lists.oasis-open.org
>  >  > cc
>  >  >                 
>  >  > Subject
>  >  >                  [wsrp] [CR308] - Add requestMethod field to
> MarkupParams
>  >  >
>  >  >
>  >  >                 
>  >  >
>  >  >
>  >  >
>  >  >
>  >  >
>  >  >
>  >  > Document: Spec
>  >  > Section: 6.1.9 MarkupParams Type
>  >  > Requested by: Subbu Allamaraju
>  >  > Old Text:
>  >  > New Text:
>  >  >   [O] string      requestMethod
>  >  >
>  >  >   . requestMethod: This field indicates the type of the HTTP request
>  >  > used by the client to submit data to the Consumer. The Consumer MUST
>  >  > supply a valid HTTP method as specified in Section 5.1.1 of RFC
> 2616 as
>  >  > a value for this field.
>  >  >
>  >  > Reasoning: In most situations, portlets can be programmed to be
> agnostic
>  >  > to how the client submitted a request to the Consumer. However, there
>  >  > are situations where a portlet must be aware of the type of the
> request
>  >  > (such as GET, POST etc.) used by the client. For example, a
> portlet may
>  >  > be acting as a proxy to fetch resources over HTTP from remote
> server. In
>  >  > this case, the portlet must be aware of the request type so that
> it can
>  >  > faithfully proxy resources.
>  >  >
>  >  > In the current protocol, portlets can dictate the method type used
> for a
>  >  > request within the markup (e.g., HTML forms, links, JavaScript
> etc). But
>  >  > portlets cannot infer the method used by the client without explicitly
>  >  > embedding it in its navigationalState for every URL created. The
>  >  > proposed optional requestMethod field will address this need.
>  >  >
>  >  > Errata? no
>  >
>  >
>
>
> To unsubscribe from this mailing list (and be removed from the roster of
> the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/wsrp/members/leave_workgroup.php.
>
>


To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrp/members/leave_workgroup.php.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]