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: Groups - Interfaces concall modified



Interfaces concall has been modified by Mr Michael Freedman

Date:  Thursday, 27 July 2006
Time:  08:00am - 09:30am PT

Event Description:
1-888-967-2253 or +44 118 924 9000 (Europe)
meeting ID: 345337
passcode: 060606

Agenda:
1) Continue to discuss portlet rendering via getResource use case as it relates to Public Review Comment concerning how Consumers handle navigational state.

Minutes:
1) discussed navState handling in getResource.  Focused on Rich's summary.  Main issue is captured in wiki.  Discussion was used to clarify issue.  Boils down to how a portlet can manage state at the action lifecycle level.  The techniques a portlet uses to do this for the above case are ineffiecient.  Considering askign the consumer to send/maintain lifecyleID instead to simplify this.  Next steps: folks think about consequences of this.  Mike to write up a proposal/detail of such lifecycleId semantics.

2) Encode Event in an URL.  Stefan presented use case from the wiki.  As use case involves the consumer parsing/discovering this at url rewrite time questions were raised concerning whether it would work with URL templates.  Stefan to think through.  Discussion transitioned to Richards proposal to make Consumer rewrite syntax extensible so new url types/additional values could be passed.  If this came into being then maybe Stefan's use case could be carried as one of these extensions.  No one raised this but there may be a similar problem with respect to templates.  Can extensions work with extensions as well?  Do we care or is it okay just to limit to URL rewrite syntax and force its use if/when extensions would be used?

3) Better support for http cache headers?  Conclusion/discussion seemed to be: useful to have well defined way to pass any request/response meta data.  Right now we pass a limited set of request meta data explicitly and leave everything else as extensions.  With respect to caching however as its explicitly expressed in the protocol it is likely better to add new fields to carry such additional data (or define a convention via an extension) i.e. a well know wsrp cache http cache meta data extension.  Likely to be continued debate on this as this information may be seen as more useful between the client and the consumer vs. the consumer/producer cache.  I.e. it may belong as client response meta data.

View event details:
http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/event.php?event_id=12252

PLEASE NOTE:  If the above link does not work for you, your email
application may be breaking the link into two pieces.  You may be able to
copy and paste the entire link address into the address field of your web
browser.

BEGIN:VCALENDAR
METHOD:PUBLISH
VERSION:2.0
PRODID:-//Kavi Corporation//NONSGML Kavi Groups//EN
X-WR-CALNAME:My Calendar
BEGIN:VEVENT
CATEGORIES:MEETING
STATUS:TENTATIVE
DTSTAMP:20060728T000000Z
DTSTART:20060727T150000Z
DTEND:20060727T163000Z
SEQUENCE:2
SUMMARY:Interfaces concall
DESCRIPTION:1-888-967-2253 or +44 118 924 9000 (Europe)\nmeeting ID:
  345337\npasscode: 060606\n\nGroup: WSRP Interfaces SC\nCreator: Mr
  Michael Freedman
URL:http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/event.php?event_id=12252
UID:http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/event.php?event_id=12252
END:VEVENT
END:VCALENDAR


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