[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp-interfaces] Re: [wsrp] Re: [wsrp-interfaces] Re: [wsrp] Enablecaching of resource content on the client
So what is the equivalence statement you made before?
This seems broken to me.
Are we then saying something like, "resources can now receive portlet
context via our brand new gR operation to enable the nice use cases you
always wanted but if you want them to perform, forget it and use the old
method"!
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
Michael Freedman
<michael.freedman
@oracle.com> To
Richard Jacob/Germany/IBM@IBMDE
02/15/07 09:24 PM cc
WSRP TC
<wsrp@lists.oasis-open.org>,
wsrp-interfaces@lists.oasis-open.or
g
Subject
Re: [wsrp-interfaces] Re: [wsrp]
Re: [wsrp-interfaces] Re: [wsrp]
Enable caching of resource content
on the client
See my reply to Stefan's e-mail. I agree with you its something that needs
to be looked at beyond 2.0 but don't think it should be addressed in 2.0 as
the portlet has the option of using http proxying.
-Mike-
Richard Jacob wrote:
ok, if this is the case, we really need to look into the caching
issue.
For efficient client side rendering using gR it seems to be crucial
for me
that the responses are cacheable by the infrastructure.
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
Michael Freedman
<michael.freedman
@oracle.com>
To
wsrp-interfaces@lists.oasis-open.or
02/15/07 08:25 PM g, WSRP TC
<wsrp@lists.oasis-open.org>
cc
Subject
[wsrp] Re: [wsrp-interfaces]
Re:
[wsrp] Enable caching of
resource
content on 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]