Re: [wsrp] [CR308] - Add requestMethod field to MarkupParams

[Subbu Allamaraju <subbu@bea.com>]

You convinced me of the issues with such a field.

Thanks

Subbu

Andre Kramer wrote:
> 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.
>