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, 08 February 2007
Time:  08:00am - 09:30am PT

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

FYI .. as a subcommittee I think its only appropriate to discuss the technical issues/merits of these items while deferring the question of its impact to 2.0 until a TC call.  That being said it will be hard to avoid such discussion but do try and remain focused.

1) Support transmitting client request/response meta data.
Mikes e-mail: http://www.oasis-open.org/apps/org/workgroup/wsrp/email/archives/200701/msg00019.html

2) Support for cookies:
Item (3) in Stefan's e-mail:

3) Support meta data for portlet-managed custom modes:
Item (4) in Stefan's e-mail:

4) meta data for next possible portlet modes
Item (5) in Stefan's e-mail:

5) Continue Ajax discussions:
Item (5) in Stefan's e-mail + various e-mails

1) Support for transmitting client request/response meta data to/from in protocol resource requests:

+ Include statement relating in-protocol support to out-of protocol support.  I.e. say the consumer pass the same information to/from the client and producer.
+ Define new field in ClientData of type NamedString[] called "mimeAttributes" which are meant to carry attributes received from the client that aren't represented elsewhere in the protocol.
+ Further define that the consumer must send those additional attributes it also sends as part of the out of protocol getResource request and that the consumer should send additional attributes to pbia and getMarkup.
+ Define a new field in MimeResponse of type NamedString[] called "mimeAttributes" which are meant to carry additional attributes relating to/describing the portlet response not represented elsewhere in the protocol.
+ Further define that for an in protocol getResource the consumer must send back to the client the same set of client response attributes it would send if this request were handled by its out of protocol method.  Also alert the portlet that in the case of pbia/getMarkup these attributes are treated as other (regular) response attributes namely as information for the consumer to use to process the response and typically do not migrate back to the client.
+ Rediscussed caching in this context and said that our statement concerning identical treatment of in-porotocl and out of band getResource should cover it -- i.e. we expect the CacheControl to get translated into client response attrbiutes.
+ Discussed existence of new cookie use case and impacts -- i.e client and portlet share state via a cookie where the client manipulates this state.  In such a case the portlet needs the cookie to make it all the way to the client but we only guarantee the consumer will cache and resupply.  Discussed cookie rewriting.  Discussed need to namespace such cookies so they don't collide -- decided the producer must be active in this so its client code can recognize the names.  Discussed that WSRP 1.0 doesn't namespace its cookies -- hence the consumer doesn't want to send all cookies back as 1.0 cookies would tend to collide.  Discussed relying on the namespace token to both prefix/namespace the cookie name as well as signify that this cookie should go back to the client.  Subbu to e-mail a more sppecific proposal.

2) Support for cookies:
GetResource needs covered by discussion above.  Action/Render needs not covered because consumer may have already emitted markup hence can't send additional headers.  Stefan to work through details of what JSR wants.

3) Defered until JSR 286 provides a more concrete definition.

4) Defered until JSR 286 provides a more concrete defintion.

5) Tabled (lack of time) until next concall (2/16 @ 8am).

View event details:

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

PRODID:-//Kavi Corporation//NONSGML Kavi Groups//EN
X-WR-CALNAME:My Calendar
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

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