[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp-interfaces] Re: [wsrp] Enable caching of resource contenton the client
I am opposed to dropping support for using portletURLs in a resource response as I expect our XPR/full-protocol Ajax support to be too cumbersome for many Ajax use cases. I.e. most portlet use cases solved with WSRP 1.0. -Mike- Richard Jacob wrote: >I think option 1 excludes the most common use case where e.g. JS libs, CSS >classes, etc. are loaded. We should still be optimized for a caching >infrastructure and offload a) the producer and b) the consumer itself. >I dont see why we should weaken that and provide a solution that from a >plain infrastructure and performance viewpoint is worse than 1.0. >I think the caching use cases are important enough to cleanly support them. > >Alternative 2 sounds feasible, in that case we would need to modify the >EBNF of the resource URL. > >Another third solution I see is to drop the support for having portlet URLs >in resources' markups. >We talked today about the symmetrical behavior of gR and HTTP resource >serving via the Consumer and the importance of having the same >functionality for both. >So enabling them in the one case while dissallowing them in the other seems >inconsistent to me. > >What was the ability added for again? Afaik we tried to solve some Ajax use >cases with it, right? >On the other and we seem to say that a solution for Ajax won't be part of >the 2.0 spec and we need to understand it more. >So here again it would seem consistent to me that we dropped that >capability and continue the Ajax discussion and add the necessary items >post-2.0. > >Mit freundlichen Gruessen / best regards, > > Richard Jacob >______________________________________________________ >IBM Lab Boeblingen, Germany >Dept. 2289, WebSphere Portal Server Development 1 >WSRP Team Lead >WSRP Architecture & Standardization >Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888 >Email: mailto:richard.jacob@de.ibm.com > > > > Stefan Hepper > <sthepper@hursley > .ibm.com> To > WSRP TC <wsrp@lists.oasis-open.org> > 02/15/07 04:30 PM cc > > Subject > [wsrp] Enable caching of resource > content on the client > > > > > > > > > > >As mentioned in one of the WSRP calls currently caching of content >served through resource URLs on the client is basically not possible for >resource that are served through gR. >Reason for this is that the resource URL that the consumer produces >needs to contain all nav state of all portlets on the page in order to >allow the gR call triggered with the URL to produce markup that contains >WSRP URLs again. This means that the URL will likely change for each >request and there will always be a cache miss on the client. >So basically there are two different use cases: >1. render a resource that contains no or only resource WSRP tokens >2. render a resource that may contain any WSRP URL token > >Solutions I see: >1. say that the requiresRewrite is used to distinguish between these two >different use cases >drawbacks: excludes use cases that only use namespacing or resouce URLs >and would normally be cachable > >2. introduce a new attribute wsrp-markupContainsPortletURLs to >distinguish between these two use cases >drawback: needs a spec change > > >If we decide to open the spec for fixing gR I would opt for 2. if not >stick with a clarification to allow 1. > >Comments? > >Stefan > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]