[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 Agenda: 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: http://www.oasis-open.org/apps/org/workgroup/wsrp/email/archives/200702/msg00000.html 3) Support meta data for portlet-managed custom modes: Item (4) in Stefan's e-mail: http://www.oasis-open.org/apps/org/workgroup/wsrp/email/archives/200702/msg00000.html 4) meta data for next possible portlet modes Item (5) in Stefan's e-mail: http://www.oasis-open.org/apps/org/workgroup/wsrp/email/archives/200702/msg00000.html 5) Continue Ajax discussions: Item (5) in Stefan's e-mail + various e-mails http://www.oasis-open.org/apps/org/workgroup/wsrp/email/archives/200702/msg00000.html http://www.oasis-open.org/apps/org/workgroup/wsrp/email/archives/200702/msg00006.html http://www.oasis-open.org/apps/org/workgroup/wsrp/email/archives/200702/msg00001.html Minutes: 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: http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/event.php?event_id=14079 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:20070208T000000Z DTSTART:20070208T160000Z DTEND:20070208T173000Z SEQUENCE:4 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=14079 UID:http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/event.php?event_id=14079 END:VEVENT END:VCALENDAR
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]