[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wsia] 10-24 Minutes
This post is for website purposes. No changes were made to the
minutes posted by Alan.
WSRP/WSIA Telecon 10/24/02
Roll
Voting Members Company
Stephen Drye Art Technology y
Group
William Cox BEA y
Adrian Fletcher BEA y
Gino Filicetti Bowstreet y
Andre Kramer Citrix y
Monica Martin Drake Certivo y
Timothy N. Jones CrossWeave y
Alan Kropp Epicentric y
Nigel Ratcliffe Factiva y
Madoka Mitsuoka Fujitsu y
Carsten Leue IBM y
Thomas Schaeck, IBM y
chair
Rich Thompson IBM y
Charles Wiecha IBM y
Eric van Lydegraf Kinzan
Jon Klein Reed-Elsivier y
Adam Nolen Reed-Elsivier y
Petr Palas Moravia IT y
Mark Cassidy Netegrity y
Olin Atkinson Novell
Chris Braun Novell y
T.J. Cox Novell y
Michael Freedman Oracle y
Mike Hillerman Peoplesoft
Sasha Aickin Plumtree y
Jane Dynin Plumtree y
Joseph Stanko Plumtree
Michael Young Plumtree y
Amir Blich SAP y
Gennady Shumaker SAP y
Yossi Tamari SAP y
Brian Dirking Stellent y
Alejandro Abdelnur Sun Microsystems y
Dave Clegg Sybase y
Joe Rudnicki U.S. Navy
Eilon Reshef WebCollage
Gil Tayar WebCollage y
Rex Brooks individual y
Steven Smith
Raj Ramesh y
Prospective Members
(non-voting)
Richard Cieply IBM
Art Machado
Ken Pugsley y
Sunit Randhawa y
WSIA Members
(non-voting)
Bruce Lucas IBM y
Ravi Konuru IBM
Graeme Riddell Bowstreet y
Minutes for 10/17 accepted
Next F2F
Starting at 10am on Monday
Rex: Are call-in numbers available yet?
JSR 168-WSRP Alignment
Thomas: three meetings this week. Summarized to lists.
Asks Alejandro, Carsten and Rich to discuss.
Alej: Need agreement on a few items for interop.
Action Definition
WSRP allows state change only in performInteraction. JSR
doesn’t have this restriction.
Rich: WSRP could allow state changes in getMarkup, or the
Producer could “mask” the issue through caching.
Mike F: The second is impractical. Would require all URL’s
are action URL’s, which isn’t acceptable.
Alan: Is the intent to attempt to solve these in this call?
Dynamic properties
Producer is permitted to handle properties that aren’t
published in the entity description. Believe this can be
handled through entity opaque state.
Alej: Can dynamic properties be modified through
setEntityProperties?
Rich: No. Only exposed properties can be modified in this
manner.
Charlie: Would like to cycle this back to next Wednesday’s
property call.
String/String[] types for properties
WSRP allows any type for property value. Not a JSR issue
since the WSRP type is a superset
Non-modifiability of properties
WSRP does not have this attribute for properties. But the
extension mechanism could be used to carry this.
Another solution was to expose only modifiable properties,
based on user context.
Ongoing JSR discussion, so this can be revisited later.
Bruce: Would be nice to understand the use cases better.
Property meta-data
JSR is far from consensus on this, so not an issue for now.
Window ID
Allow Producer to provide private scope mapped to a
particular entity on a page (window).
WSRP sends entityHandle on initial page view, the Producer
at that point can encode the window ID in the refHandle.
Mike F: Don’t want to have to use the refHandle for this.
It should be passed over as add’l data, from the Consumer
Gil: Goes back to old discussion. RefHandle was intended
for just this sort of possibility.
Mike F: No. This will lead to performance/scalability
problems.
Rich: Instead of encoding it in the refHandle, could encode
it as a cookie.
Mike F: Cookies could get quite large. Would prefer we
pass it explicitly in the protocol, or the JSR decides on a
suitable extension for WSRP interop.
Bruce: Consumer-managed refHandle. Consumer encodes the
window ID.
Carsten: Doesn’t this blur the refHandle? We had agreed
that refHandles are always Producer-managed.
Mike F: We should open an issue for discussion.
Alej: And JSR should discuss possible extension.
CSS prefix
Concern with “wsia:” prefix. Propose “portlet:” instead.
Charlie: “markup-fragment”?
Chris: That would be very long. The class names themselves
are long enough.
Rich: we should open an issue, this has been on the
backburner for a while.
Thomas: “markup:” as a placeholder?
Extensions
JSR allows string name-value’s. WSRP allows <any/> schema
elements. WSRP should adopt name-value’s as well.
Should still be possible for JSR to come up with protocol
extensions to handle WSRP extensibility (DOM parsing, etc.).
Charlie, Carsten: Would all JSR portlets then essentially
require this extensibility for WSRP compliance?
Thomas: Would like a proposal that achieves
interoperability without requiring a protocol extension.
Mike F: As an intermediate proposal, we could use the
property arrays in getMarkup/performInteraction, since
they’re string name-values anyway, and then the return
structures would need to include a response property list
array.
Charlie, Bruce, et al: Why not define a content model that
allows JSR to interpret the <any> as string name-values?
Mike F: The problem with the <any> model is that it’s not a
Least Common Denominator approach.
Bruce: It’s pretty trivial to carry string name-values in
the <any> element.
Rich will write up a resolution.
Allowed portlet modes/window states
WSRP doesn’t convey allowed modes/states in
getMarkup/performInteraction.
Carsten: In WSRP, the mode is completely managed by the
Consumer.
Alej: But what about when the portlet is finished in one
mode, eg. Edit, and needs to transition back to View?
Rich: We don’t want to reinvent XACML
Carsten: Why not allow the portlet to manage mode/window
state change?
Alej: It doesn’t have all of the information, ie, current
interaction context, that the Consumer does.
Thomas: Portlet could generate markup for a given
mode/window state, and Consumer is free to reject it, and
resubmit a request for the correct mode/window state.
Alej: That could break transactions. When Consumer
resubmits, previous info could be lost.
Mike F: We should move on, with 10 minutes remaining.
Caching
JSR does simple expiry caching. Waiting to see outcome of
WSRP caching discussion.
Copy-on-write
Waiting on WSRP discussion.
Mode and window state constants
Have proposed that WSRP simplify the names (issue submitted)
Meta-data localization
J2EE 1.4 will use the HTML xml-lang attribute.
Gil: This complicates rpc-style interface development
Rich: We already can’t do rpc-style due to prior problems.
User information
JSR could have an appendix of common name mappings.
WSRP expresses user attributes as structured data. JSR will
have to deconstruct this into name-values.
Uploading data
JSR allows upload data in both performAction/render…WSRP
only allows this in performInteraction. Related to action
issue
Valid modes by contentType
JSR allows for modes by contentType. WSRP does not
distinguish allowed modes this way.
Rich: Does this come from the entity description?
--
Rex Brooks
Starbourne Communications Design
1361-A Addison, Berkeley, CA 94702 *510-849-2309
http://www.starbourne.com * rexb@starbourne.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC