WSRP/WSIA Telecon 10/3/02

Roll

Voting Members

Company

 

Stephen Drye

Art Technology Group

 

William Cox

BEA

Y

Adrian Fletcher

BEA

 

Gino Filicetti

Bowstreet

Y

Andre Kramer

Citrix

Y

Timothy N. Jones

CrossWeave

 

Peter J. Quintas

Divine

 

Alan Kropp

Epicentric

Y

Nigel Ratcliffe

Factiva

 

Madoka Mitsuoka

Fujitsu

 

Carsten Leue

IBM

Y

Thomas Schaeck, chair

IBM

Y

Rich Thompson

IBM

Y

Charles Wiecha

IBM

Y

Eric van Lydegraf

Kinzan

Y

Joe Klein

Reed-Elsivier

 

Adam Nolen

Reed-Elsivier

 

Petr Palas

Moravia IT

 

Mark Cassidy

Netegrity

Y

Olin Atkinson

Novell

Y

Chris Braun

Novell

Y

T.J. Cox

Novell

Y

Michael Freedman

Oracle

Y

Mike Hillerman

Peoplesoft

 

Andrew Sweet

Perficient

 

Sasha Aickin

Plumtree

Y

Jane Dynin

Plumtree

Y

Joseph Stanko

Plumtree

Y

Michael Yound

Plumtree

 

Yossi Tamari

SAP Portals

Y

Stephen A. White

SeeBeyond

 

Ugo Corda

SeeBeyond

 

Brian Dirking

Stellent

Y

Alejandro Abdelnur

Sun

Y

Dave Clegg

Sybase

 

Joe Rudnicki

U.S. Navy

Y

Eilon Reshef

WebCollage

 

Gil Tayar

WebCollage

 

Prospective Members (non-voting)

 

 

Gennady Shumaker

 

Y

Rex Brooks

 

Y

Richard Cieply

IBM

 

Steven Smith

 

Y

Art Machado

 

Y

Ken Pugsley

 

 

Raj Ramesh

 

 

Monica Martin

Drake Certivo

 

WSIA Members

(non-voting)

 

 

Bruce Lucas

IBM

Y

Graeme Riddell

Bowstreet

Y

 

 

 

 

Alan:  At the beginning of the meeting, less than a quorum was present, deferring votes.  Next week, we’ll wait a minute or two longer, but if everyone could please be on time, that would help a lot.  Thanks!

Prospective members:  Could you please confirm your name and company affiliations.

WSIA members:  If I missed you, please let me know.

Bill Cox:  We need to be sure to review the minutes carefully.

Thomas:  Agreed.

Group ID

Mike F.:  Would like to understand the semantics of group ID.  Original F2F consensus against modeling shared sessions.  Defer in favor of an event mechanism.  What is the value over and above being a vendor extension?

Andre:  groupID makes explicit in the protocol the association betw. Consumer/Producer, and if groupID is dropped would only be reflected in the transport.

Mike F:  What would the semantics be?

Mike F:  The assumption would have to be that multiple instances of an entity could be in a group.  No guarantee of the size of the group, or number of instances that may be in.  Must code the Producer accordingly (namespace collision, etc.).

Mike F:  initEnvironment and groupID are separate issues.

Carsten:  Disagree, they are related.

Rich:  Spec refers to a SHOULD requirement that the Consumer should group portlets to enable Producer sharing.

Yossi:  How does Consumer know how to group portlets?

Mike F:  This seems like a vendor extension.

Rex:  Think it’s more of a placeholder for future functionality.

Mike F:  It’s better to leave it out, rather than allow implementations to code to it and then it changes.

Carsten:  Doesn’t the JSR have an APPLICATION scope?  We need groupID to support it?

Mike F:  True, but the Consumer is in no position to perform APP-level grouping, without detailed meta-data about how it structures its own applications.  And we decided to defer this level of meta-data/grouping semantics from 1.0.

Yossi:  Wouldn’t object to having an extensibility mechanism in initEnvironment.  Mike F:  Agree.

Carsten:  Want to see detailed JSR scenario without groupID on the email list.

Consumer MAY or MUST release handles?

Andre, Mike F:  Seems too rigid to be MUST…network failures, etc.

Rich:  If it’s MAY, Consumers might just avoid using it altogether.

Thomas:  MUST attempt at least once?

This seemed reasonable.

Rich:  Editorial task to reword.

Consumer name unique?

Mike F:  Why does it have to be unique?

Rich:  Good question.  Came in from an early requirement, typically the Consumer would use it’s URL.

Mike F:  How about wording such that the Consumer SHOULD endeavor to uniquely id itself, typically by using its URL.

Rich:  Good.

Specify storage of consumer handle?

Rich:  0.7 spec reflects rewording according to Sasha’s point.

ModifyRegistration should (not) return consumer handle?

Rich:  0.7 factored return types, so it no longer returns consumer handle.

Mike F:  Does anything get returned?

Rich:  Yes…state, and <any>

Mike F:  Can Consumer determine if either of these have actually changed?  Or does it assume they did change?  Minor point…

Rich:  The usual null-return semantics should apply, but the wording doesn’t yet reflect that.

CloneEntity allows immediate property modification?

Rich:  0.7 draft reflects F2F decision not to merge property modification into other operation signatures.

PreviousMode and previousWindowState?

Rich:  0.7 draft has a default mode or window state, in case the Consumer does not have or specify a previous mode or window state.

Alejandro:  Previous request, or previous different?

Mike F:  Is this historical based on old discussions in the JSR?

Sasha:  What is the use case?

Mike F:  Can we drop these?

Rich:  The early F2F use case was to know what mode to return from HELP mode to…but the Producer could certainly remember the original mode itself. 

Rich:  Open an issue to drop them.

MarkupType is MIME?

Maximum size of a handle

Yossi:  The handle should be a key (hash) to the state itself.  (Option 1 as listed in the agenda).

Mike F:  Why should this be a Consumer problem and not a Producer problem?

Sasha:  Putting a limit on this is likely to cause pain at some point.

Mike F:  Many of these handles need to be stored in memory, so limiting the handle size does make sense.

Alejandro:  Producer meta-data could specify how large its handles are?

Thomas:  This affects plug-and-play.  There should be a standard handle size.

Lots of discussion, partly obscured by noise on the line (can folks please remember their mute buttons?)

The argument basically boils down to:  If there is a limit, than it’s bound to be too restrictive for somebody.  On the other hand, if there’s no theoretical limit, than that leads to inefficiencies, particularly for the Consumer who has to store these handles in memory.

Alejandro:  Is there a middle ground?  We’ve been talking about practical large limits, 2K, etc.

The discussion continues, veering dangerously into redesign by committee of refHandle semantics..

Rich:  Continue email discussion, people can list pros/cons to the 3 options.

<any> extensibility mechanism

Rich:  Axis has a bug regarding handling of the namespace, but there is a simple workaround.  JAX-RPC also has a problem with the WSDL.

Mike F:  JSR is going to avoid use of the <any> mechanism, because it’s more efficient not to have the marshalling logic to handle the typed content.  More efficient to use Strings.

GetMarkup modify/return state?

Mike F:  What is meant by ‘state’?

Rich:  Stateful sorts of things that could change is session creation, and anything stored within a session.

Mike F:  That should include any state that is entirely managed by the Producer…modified state gets returned.

Thomas:  This could be a problem for aggregation.

Mike F:  Would like to have details on the problem.  JSR strong preference is for entity state to change in getMarkup.

Can a refHandle be passed to destroyEntities?

Rich:  Consensus from email seems to be no.

Mike F:  In effect there would be no way to terminate a session explicitly. 

Rich:  We should open this as a new issue.

Review resolutions from F2F

Rich:  It would be good to get people to review these, and comment as needed.