OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-interfaces message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wsrp-interfaces] Multi-section rendering (Renamed)



One might think that the Consumer could simply filter the list of resources such that each is included only once per page, but such an approach is problematic. Most resources are not "shareable"; that is, they are not fully instance based such that two uses do not end up stepping on each other. Unless a resource is known to be shareable, the only safe thing for the Consumer to do on an html page is to wrap portlets with a second reference to a resource in an IFrame such that the browser provides the isolation that is potentially required. The item this point out to me is that we do not include a means to indicate a resource is shareable today (note this is not equivalent to being broadly cacheable) ... perhaps that needs to be added.

Rich



From: "Nathan Lipke" <nlipke@bea.com>
To: "Michael Freedman" <michael.freedman@oracle.com>, <wsrp-interfaces@lists.oasis-open.org>
Date: 11/07/2007 09:44 PM
Subject: RE: [wsrp-interfaces] Multi-section rendering (Renamed)





Some of my team members came up with an interesting use case related to this and I wanted to get some feedback:
 
Several portlets may share a common scripts or styles (e.g. Dojo). Some thoughts:
1.        Is there anyway to tell the consumer it does not need to call getMarkup() for each portlet.
a.        Possibly a grouping mechanism
                                                               i.      Can/should this be related to cookie groups
2.        Can the consumer merge head tags (link and script) that refer to the document?
a.        What about tags with bodies?
 
Not solving this could cause large amounts of network traffic and worse multiple running of scripts not intended to do so.
 
Any thoughts, thanks,
 
Nate
 



From: Michael Freedman [mailto:michael.freedman@oracle.com]
Sent:
Wednesday, October 24, 2007 4:32 PM
To:
wsrp-interfaces@lists.oasis-open.org
Subject:
Re: [wsrp-interfaces] Multi-section rendering (Renamed)

 
Additional questions:
1) What does it mean to have differing markupsections return non-null clientAttributes?
2) Would it be better if the cacheability level is carried as an extension in CacheControl vs where you have it?
   -Mike-

Rich Thompson wrote:


My comments in prep for tomorrow's call (in document order):

1.        Is there a proposed QName for this extension? We have normally put this in the top-level header, but it certainly can be added late as that allows the settled semantics to be better represented.
2.        For completeness the second paragraph should also indicate how the Consumer indicates support for the extension.
3.        This may just be phrasing, but is the conformance statement in the second paragraph suggesting getMarkup invocations for each portlet-specified section or just that each specified section should be requested? I ask because one can debate whether SHOULD is too strong of conformance language given the ability to make valid arguments favoring differing implementation styles (in particular, one call per section vs one call for all sections). We will also need to think carefully through cases where the portlet specifies a section which the Consumer has no idea how to handle (e.g. TabHeader).
4.        It wasn't obvious to me how different caching for each section was included until I dug into the schema. I suggest the descriptive text be more explicit about how the distinct information is returned. Once I had dug into this, the question arose as to whether MarkupContext was the right base for MarkupSections to extend. I suspect additional sections have more in common with resources than with the portlet's main markup and therefore MimeResponse would be a more appropriate base.
5.        In 11.3.3, I would recommend rewording the duplicate conformance statement to eliminate the duplication. This both stops it from looking like an additional requirement and reduces likelihood of a later mismatch between the statements.
6.        11.3.3 should require that all specified section names match the Portlet-specified ones.
7.        I would drop the complexity regarding choosing the main section. If wsrp-extra:body is requested, it appears in the main section. All other requested sections appear in extension fields.
8.        Why would the default cacheability be "full" for sections when it is "page" for the main markup? Do we have good reasons for thinking most sections will be reusable across all users, navStates, modes and windowStates or is this just an internal inconsistency developers will struggle with?


Rich

From: "Nathan Lipke" <nlipke@bea.com>
To: "Nathan Lipke" <nlipke@bea.com>, "Michael Freedman" <michael.freedman@oracle.com>, <wsrp-interfaces@lists.oasis-open.org>
Date: 10/16/2007 07:15 PM
Subject: RE: [wsrp-interfaces] Groups - Interfaces concall added

 







I added in cacheability based on wsrp-resourceCacheability.

 
Thanks,

 
Nate

 

 



From:
Nathan Lipke [
mailto:nlipke@bea.com]
Sent:
Wednesday, October 10, 2007 3:18 PM
To:
Michael Freedman;
wsrp-interfaces@lists.oasis-open.org
Subject:
RE: [wsrp-interfaces] Groups - Interfaces concall added

 

Thanks for the feedback,

 
Attached is a second draft which allows for multiple sections to be sent and received in a single request. It still allows for individual sections to be cached with their own unique validate tag.

 
--

Nate

 

 



From:
Michael Freedman [
mailto:michael.freedman@oracle.com]
Sent:
Tuesday, October 09, 2007 4:39 PM
To:
wsrp-interfaces@lists.oasis-open.org
Subject:
Re: [wsrp-interfaces] Groups - Interfaces concall added

 

Again inline:

Nathan E Lipke wrote:
I'll work on rewriting this tomorrow. See comments inline.

Michael Freedman wrote:
See inline:


Nathan E Lipke wrote:
If you think a more generic solution is needed with regards to sections, how does the following sound?


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]