Re: [wsrp-interfaces] tie method=get to getMarkup

[Richard Jacob <richard.jacob@de.ibm.com>]

Right, and having that said the anology for an idempotent operation in WSRP
is getMarkup().
That's why I proposed to add support for such form params in the markup
params.

Mit freundlichen Gruessen / best regards,

        Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
WSRP Team Lead & Technical Lead
WSRP Standardization
Phone: ++49 7031 16-3469  -  Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com


                                                                           
             Subbu Allamaraju                                              
             <subbu@bea.com>                                               
                                                                        To 
             07/13/2005 02:38          wsrp-interfaces@lists.oasis-open.or 
             AM                        g                                   
                                                                        cc 
                                                                           
                                                                   Subject 
                                       Re: [wsrp-interfaces] tie           
                                       method=get to getMarkup             
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




My take is that, HTTP has been very clear from the beginning that method
GET is most suited for idempotent requests, and that GET requests can be
replayed without side effects. Ideally, web developers should be using
GET forms for queries (e.g. a catalog search) and I agree with Richard
and Andre on that.

Given this, I don't think the GET support is for legacy. Most HTTP and
REST advocates would definitely disagree with WSRP if we take the
opposite path (i.e. encourage POST always). You are right that some
consumers out there today do not support method GET in forms due to more
complex rewriting rules, but in time, I'm sure that will change.

Subbu

Michael Freedman wrote:

> I am torn on this one.  Though I understand the technical logic of this
> proposal, I am against anything that encourages less interoperability .
> From my perspective our support of form GETs were a bow to legacy
> implementations with a recognized cost to the producer of a lack of
> interoperability.  Yes, allowing producers with such legacy code to
> represent their Form GETS as "renders" is most natural however I want to
> encourage these developers to update their code to rely on POST anyway
> so they run in all consumers.  Forcing the use of PBI [the POST style]
> nudges them down this path.
>     -Mike-
>
> Richard Jacob wrote:
>
> >It seems that we didn't discuss this issue seperatly and that the
> >discussion got stuck concerning this.
> >I was asking, as a side discussion, to tie forms with method=get more
> >explictly to getMarkup().
> >The reasoning for this is mainly that it would comply to the W3C
> >architecture (http://www.w3.org/TR/webarch/) and would enable use cases
> >where portlets use forms and add parameters to forms dynamically for
> their
> >navigation (not for changing state).
> >As one example I raised then, was how to solve the "URL manipulation"
> >requirement Rich raised by using forms with method=get and
> dynamically add
> >form params.
> >
> >This would basically mean that we would need to:
> >- add form params to MarkuParams which would be passed with getMarkup.
> >- the consumer SHOULD map method=get form submissions to getMarkup()
> >requests. Remember method=get simply fetches a resources and should not
> >modify the server side state, therefor we can define these form
> params as
> >part of the navState. I.e. currentPortletNavState(encoded in
> >URL)+publicNavState(dynamically added)=resultingNavState for which the
> >portlet renders its markup.
> >One additional advantage here (in contrast to handling it via pbia()) is
> >that the Consumer can compute the cache key for that
> resultingNavState and
> >thus be able to cache this markup.
> >
> >The advantages I see:
> >- natural representation of method=get as resource/markup fetching in
> >contrast to state changes in pbia()
> >- conformance to W3C arch
> >- enables cachability of pages using method=get uncluding their
> invokations
> >results, i.e. if zipcode is a form field, consumers can cache portlet
> >markup with zipcode=10000 and zipcode=20000. (yes, invalidation caching
> >would help :-) but we don't have it yet)
> >- enables searchability and crawlability of portlets using such forms
> >
> >Mit freundlichen Gruessen / best regards,
> >
> >        Richard Jacob
> >______________________________________________________
> >IBM Lab Boeblingen, Germany
> >Dept.8288, WebSphere Portal Server Development
> >WSRP Team Lead & Technical Lead
> >WSRP Standardization
> >Phone: ++49 7031 16-3469  -  Fax: ++49 7031 16-4888
> >Email: mailto:richard.jacob@de.ibm.com
> >
> >
> >
>
>