[wsia] 10-17 Minutes

MHonArc v2.5.2 -->
















wsia message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [Elist Home]








Subject: [wsia] 10-17 Minutes




From: Rex Brooks <>
To: 
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
MembersCompany

Stephen DryeArt Technology
Group

William
CoxBEAy

Adrian
FletcherBEAy

Gino
FilicettiBowstreet

Andre
KramerCitrixy

Timothy
N. JonesCrossWeavey

Monica
MartinDrake Certivoy

Alan
KroppEpicentricy

Nigel
RatcliffeFactiva

Madoka
MitsuokaFujitsu

Carsten
LeueIBMy

Thomas
Schaeck, chairIBMy

Rich
ThompsonIBMy

Charles
WiechaIBMy

Eric van
LydegrafKinzany

Jon
KleinReed-Elsivier

Adam
NolenReed-Elsiviery

Petr
PalasMoravia
ITy

Mark
CassidyNetegrityy

Olin
AtkinsonNovelly

Chris
BraunNovelly

T.J.
CoxNovell

Michael
FreedmanOracley

Mike
HillermanPeoplesofty

Sasha
AickinPlumtreey

Jane
DyninPlumtreey

Joseph
StankoPlumtree

Michael
YoungPlumtreey

Gennady
ShumakerSAPy

Yossi
TamariSAPy

Brian
DirkingStellenty

Alejandro AbdelnurSuny

Dave
CleggSybasey

Joe
RudnickiU.S.
Navyy

Eilon
ReshefWebCollagey

Gil
TayarWebCollagey

Rex
Brooksindividualy

Raj
Rameshy

Steven
Smithy


Prospective
Members (non-voting)

Richard CieplyIBM

Art
Machado

Ken
Pugsley

Amir
BlichSAPy

Sunit
Randhaway

WSIA
Members

(non-voting)

Bruce LucasIBMy

Ravi
KonuruIBMy

Graeme
RiddellBowstreet




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 * 
















[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [Elist Home]


  









Powered by eList eXpress LLC