[wsia] 10-3 Minutes for Website

[Rex Brooks <rexb@starbourne.com>]

Hi Folks, This Post is just for the purpose of ease in getting the
minutes onto the website.



WSRP/WSIA Telecon 10/3/02

Roll

Voting MembersCompany

Stephen Drye Art Technology Group

William CoxBEA 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 RudnickiU.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 MartinDrake 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.






--
Rex Brooks
Starbourne Communications Design
1361-A Addison, Berkeley, CA 94702 *510-849-2309
http://www.starbourne.com * rexb@starbourne.com