Subject: Re: [wsrp] Re: Q about resource usage with http post
I would like to emphasize the problem that Lars has described in detail below. In transaction-oriented highly interactive systems, such background interaction where only optimized pieces of the page are being refreshed instead of the whole page is increasingly becoming the rule instead of an exception. One may argue that the combination of HTTP+HTML was not designed to support such interaction but that's a moot point as we have to live within these limitation until rich clients bring back a smarter version of client-server. In the past few months, I have had discussions with quite a few content providers around the technical aspects of WSRP. More than a few have described it as a standard that is not fully baked out or is out of touch with reality. If you probe a little further one of the complaints that surfaces almost immediately has to do with the technical limitations that WSRP puts on highly frequent user interaction. Complaints ranging from mandating the consumer as the ubiquitous proxy essentially slowing down every single request to the implicit assumption that refreshing the whole page with every request would be acceptable to users in the real world. For example, in this case we will have to be forced to use the resource template and go directly to the content server whenever partial page refresh is involved. We don't want to do that and it is not an optimal design but the limitations of the spec will force us in this direction. Otherwise we don't support WSRP at all but that will not provide value to our customers and also significantly weaken the standard. It's time that the 2.0 version and subsequent specs focuss on the interactive systems and take requirements from them. We should try to accomodate those requirements in 2.0 and subsequent specs even if it means breaking the theoretically pleasing aspects of the spec. The bottom line is that the spec is useless until and unless content providers support it. We already have all the leading portal vendors supporting WSRP consumption but little non-trivial activity on production. What will make this standard viable and popular is the rapid increase in the number of content providers supporting it for production. Issues like the one that Lars has stated in his mail below present a significant road-block for achieving that vision. PeopleSoft is a leading provider of highly interactive enterprise applications. We will continue to work with the WSRP committee to make it into a more feasible standard for us and for other content providers who are facing problems that are similar to us. In my opinion, to enable wide adoption of this spec among producers, we will need a shift in the way we approach it -- a shift away from a portal vendor perspective to a interactive content provider's perspective. Without such a shift, we might end up with thousands of earnest consumers with nothing to consume. Thanks, Khurram lars_hofhansl@peo plesoft.com To: firstname.lastname@example.org cc: email@example.com, (bcc: Khurram Mahmood/PeopleSoft) 09/24/2004 10:03 Subject: Re: [wsrp] Re: Q about resource usage with http post AM We have potentially a lot of information to send; more than the maximum size of a URL (which is also browser dependent). We could chunk the information, send multiple GET requests and re-assemble the fragments on the server, but I'd rather perform a simple POST. There are also security issues. POSTed information is automatically secure when using SSL, for GET encoded data we'd have to do our own encryption (for example if access logging is enabled on the server where the resource is served from). -- Lars "Rich Thompson" <firstname.lastname@example.org To: email@example.com m> cc: (bcc: Lars Hofhansl/PeopleSoft) Subject: Re: [wsrp] Re: Q about resource usage with http post 09/23/2004 12:20 PM As I read your first paragraph, I also went to using the concept of resources as the right way to accomplish what you need (i.e. the updated fragment is a resource from the Consumer's point of view). Is there a particular reason the information you want to transfer has to be via http post rather than get? This sounds a lot like some of the things I did in a previous research project, but we used http get for all the transfers. Rich firstname.lastname@example.org 09/23/2004 02:35 PM To email@example.com cc Subject [wsrp] Re: Q about resource usage with http post In our case we are implementing a mechanims for "selective page refresh" using DHTML. I.e. we have to completely bypass the Portlet Interaction model. There seems to be no specific provision for this in the WSRP Spec (V1). For example performBlockingAction() either has to return the complete markup or it has to be followed by getMarkup(), we can't just return some change information and partially update a portlet. (I realize that when multiple portlets are displayed by a Consumer and one of the portlets needs to be re-rendered that the Consumer may re-render all portlet, which breaks our selective refresh paradigm for that case.) For these reasons we're trying to POST to resourceURL in order to handle our data exchange, then update the representation using DHTML based on the exchanged information without triggering any (Consumer visible) refreshes in the Consumer. Now, the V1 WSRP spec in 10.2.1.1.3.1 says that the cosumer is "encouraged to use the same communication style (e.g. HTTP Get or POST)" that was used by the user-agent. That does not seem to mandate that behavior and thus we cannot assume that all Consumers will indeed behave that way. Thanks. -- Lars Rich Thompson wrote: I don't know of cases where people have used http post in this manner, but the spec anticipates that such cases may exist and allows the markup to specify use of post with the requirement that the Consumer then also use post when passing the request on to the resource url. This keeps the Consumer truly acting as a proxy for these resources. Rich firstname.lastname@example.org 09/21/2004 05:36 PM To email@example.com cc Subject [wsrp] Q about resource usage with http post Is HTTP post supported for resource operations according to the spec? My reading of it points to an ambiguous statement to that effect on pg 62, section 10.2.1.1.3.1 Thanks 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 . 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 .