wsia message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: [wsia] 10-17 Minutes
- From: Rex Brooks <rexb@starbourne.com>
- To: wsia@lists.oasis-open.org
- Date: Thu, 17 Oct 2002 17:50:25 -0700
Title: 10-17 Minutes
Hi Folks,
This is a copy of the minutes Alan posted, for website
purposes.
WSRP/WSIA Telecon
10/17/02
Roll
Voting
Members Company
Stephen Drye Art Technology
Group
William
Cox BEA
y
Adrian
Fletcher
BEA y
Gino
Filicetti
Bowstreet
Andre
Kramer Citrix
y
Timothy
N. Jones
CrossWeave
y
Monica
Martin
Drake Certivo y
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
Jon
Klein
Reed-Elsivier
Adam
Nolen
Reed-Elsivier y
Petr
Palas Moravia
IT
y
Mark
Cassidy Netegrity
y
Olin
Atkinson
Novell y
Chris
Braun Novell
y
T.J.
Cox
Novell
Michael
Freedman
Oracle y
Mike
Hillerman
Peoplesoft
y
Sasha
Aickin Plumtree
y
Jane
Dynin Plumtree
y
Joseph
Stanko
Plumtree
Michael
Young Plumtree
y
Gennady
Shumaker
SAP y
Yossi
Tamari SAP
y
Brian
Dirking
Stellent
y
Alejandro Abdelnur Sun
y
Dave
Clegg Sybase
y
Joe
Rudnicki U.S.
Navy
y
Eilon
Reshef WebCollage
y
Gil
Tayar
WebCollage
y
Rex
Brooks individual
y
Raj
Ramesh
y
Steven
Smith
y
Prospective
Members (non-voting)
Richard Cieply IBM
Art
Machado
Ken
Pugsley
Amir
Blich
SAP y
Sunit
Randhawa
y
WSIA
Members
(non-voting)
Bruce Lucas IBM
y
Ravi
Konuru IBM
y
Graeme
Riddell
Bowstreet
Minutes
last week accepted
Prospective members who've attended 3 meetings to be
voting members.
Review
Tentative Resolutions
31, 35, 23, 34, 57, 74 are still open
All
other issues will be closed by tomorrow, pending any other
objections.
#24 Previous
window state and mode
RemoveŠpropose vote?
Gil:
Request from Consumer?
Rich:
From Consumer to Producer, it's information. Vice versa,
it's a request to change.
Carsten: F2F decision was that mode is managed
by Consumer.
Motion: Remove constants and semantics
related to previous window state and previous mode?
26
yes, 0 no, 3 abstain
#26/#94
isRefresh and getMarkup returning state
Alejandro: JSR does not model isRefresh.
JSR does allow property change in getMarkup (render). Would like
WSRP to consider having getMarkup do property changes.
Thomas:
How important is this to JSR?
Alej:
No clear reason to limit developer flexibility. We have some use
cases
Thomas:
Summarize use cases?
Alej:
blocking/non-blocking action. If you're not changing state,
yet still performing an action, it would be more efficient to do one
roundtrip.
Rich:
the question is putting a burden on the developer to ensure that state
changes during getMarkup are "safe".
Mike F:
It shouldn't be a MUST, more of a strong
recommendation.
Charlie: There's not presently a mechanism in
getMarkup to carry property changes.
Bruce:
So this just means that some JSR portlets aren't WSRP
compliant.
Thomas:
WSRP and JSR do need to be consistent.
Gil:
How does JSR intend Consumer to do copy-on-write
semantics?
Alej:
Is copy-on-write part of WSRP. Hard to model in
JSR.
Thomas:
Should this be re-discussed in the JSR?
Alej:
I have problems with the copy-on-right programming model. Seems
like odd semantics.
Thomas: We should set up a separate call to
discuss this topic.
Mike
F: Still need to hear the main objections to allowing state
changes in getMarkup.
Thomas:
getMarkup would need to have the stateChangeOK flag, and the
copy-on-write scenario could occur either way. Also if an entity
is shared, parallel getMarkup could cause collision.
Rich:
(to Alej) you're withdrawing #26. Alej:
Yes.
Rich:
Does the copy-on-write semantics in the draft reflect the F2F?
(consensus: Yes).
Alej:
One objection would be if there is a txn covering the
interactionŠyou'd need to rollback if there was a copy-on-write
"fault"? That's complex.
Gil:
But the Producer would know ahead of time that it MAY make changes to
persistent state.
Thomas:
Some backend changes wouldn't necessarily be reflected in
properties..i.e., opaque state changes could trigger a
copy-on-write.
Gil:
Backend changes aren't the issue for this model. It's
user-specified changes that are important, and that's what the flag
is for.
Rich:
Email discussion around this: Andre raised the issue that
cloneEntity(refHandle) actually means cloning the runtime state.
Also Mike F's observation that the flag could be tri-state, for
better efficiency.
Carsten: This is an optimization?
Rich:
That was my first response.
Gil:
Drop stateChangeOK=False?
Charlie: This could be carried by access
restriction instead.
Rich:
Would prefer a larger-grained (than request level)
restriction.
Alej:
Email the main ideas.
Rich
or Mike will email
Carsten: Recall from early F2F that we don't
create entities "under the hood". This has
changed?
#6 groupID
required?
Rich: either remove it, or keep it but improve
the semantics.
Carsten: If removing it, that means that there
is one JSR Producer to an application.
Mike F:
That's not a hard requirement. The Producer could distinguish
which entities belong to which applications. The Producer could
itself do the grouping opaque to the Consumer.
Carsten: Doesn't this break load
balancing
Mike F:
Yes, but that's J2EE semantics. If you put everything in one
Producer, it's not going to be load balanced anyway.
Alejandro: Why is load balancing broken in this
case?
Carsten: Current JSR requires same HTTP
session. Without information from the Consumer, how can the
Producer partition entity runtime state cross-cluster?
Mike F:
Producer is load balanced, but the applications are not. If the
Producer wants to do app-level load balancing, it will need to do
special handling.
Andre:
Still think it could be done by forwarding the
request.
Mike F:
But that's still not the servlet model. Andre:
Agree
Andre:
With groupID, you could accomplish more than one HTTP
connection.
Mike F:
That's specific to the SOAP stack. Some stacks could allow you
to move cookies between connections. But that's regardless of
the groupID question.
Mike F:
Still look at this as a vendor extension. Haven't seen a
convincing proposal for how the Producer would find this
useful.
Carsten: JSR requires one session per
application. GroupID is one such mechanism. Or could have
mandatory metadata that assigns portlet groupings that the Consumer
must honor.
Mike F:
Why does the spec "fall apart" without groupID?
Carsten: Imposes great complexity on the
Producer because the "special handling" required to do
necessary grouping, i.e. JSR app-scope.
Mike F:
Your definition of groupID is a set of entities?
Carsten: Yes
Andre:
We're likely to not want to rely on transport-specifics like
cookies. We still want grouping for Consumer-specified
sharing.
Mike F:
That's different from Producer partitioning, which is Carsten's
main concern.
Thomas:
Should have one well-defined sharing semanticŠJSR?
Mike F:
Yes. Worries about the slippery slope of considering other, ie.
Consumer, specified sharing semantics.
Andre:
Specializations could be built off the groupID, without breaking
interoperability.
Mike F:
Agree. But it's expressed as an extension. Still think
we can carry the grouping information as metadata, remove groupID from
the protocol.
Carsten: That makes us transport
protocol-dependent. I could live with this as a bare
minimum.
Rich:
Two proposals: Producer metadata instructs Consumer about how it
needs to call initEnvironment, or states initEnvironment isn't
needed.
Carsten will write up metadata proposal, circulate
it among Rich, Andre, et al.
#84
secureClientCommunications more than a Boolean?
Rich: How slippery a slope? Could become
very involved
Sasha:
Boolean doesn't express much.
Rich:
This could be expanded on in the SOAP header in later
versions.
Sasha:
That's fine. I don't feel strongly about it, so it could be
withdrawn.
Alej:
JSR exposes if client connection is secure (Boolean), and also auth
types.
Rich:
How does this play if there are more than one hops between Consumer
and Producer?
Alej:
Shouldn't it be a String to carry auth type?
Mike F:
It's a separate issue, so we should track it as a potention interop
issue between JSR and WSRP.
Gil:
This is useful info to carry, since WSS probably won't carry
it.
--
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