Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 42920 invoked from network); 13 Mar 2006 16:21:56 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 13 Mar 2006 16:21:56 -0000 Received: (qmail 43106 invoked by uid 500); 13 Mar 2006 16:21:52 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 43057 invoked by uid 500); 13 Mar 2006 16:21:52 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Delivered-To: moderator for dev@geronimo.apache.org Received: (qmail 10411 invoked by uid 99); 13 Mar 2006 15:06:11 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of chirino@gmail.com designates 64.233.184.201 as permitted sender) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references; b=GrNETc8djhkKivWqASjGf+W6m7vDNfVyfzTvQf1/tQnlsC/HvrNYGxoh7B5zxf92lULJBz5PjpsGZ2TgVmIA/nphbdZqyUtLZAIyhnIXyNFKhoGHVBRv/8DClS5esj1iut2BLfyay0KhcxoZLGMhkj53JQIof22YUi5Rq+FpHMU= Message-ID: Date: Mon, 13 Mar 2006 10:05:46 -0500 From: "Hiram Chirino" Sender: chirino@gmail.com To: dev@geronimo.apache.org Subject: Re: Summary? was: Session API.... In-Reply-To: <44101B00.8010205@coredevelopers.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6139_33326047.1142262346754" References: <1F5F68F5-2E35-4AAF-B90B-072081D34FE7@gmail.com> <4406A4CA.7080501@mortbay.com> <8BD915E8-7E9B-423C-BAE0-30848C10DA49@iq80.com> <440855A4.4060406@mortbay.com> <50B7DE47-82DB-4F5B-AD61-2B2AACC1AE35@iq80.com> <440BF78E.2000802@mortbay.com> <79A344F8-8D67-4957-81FD-A1698EC86101@iq80.com> <44101B00.8010205@coredevelopers.net> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_6139_33326047.1142262346754 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 3/9/06, Jules Gosnell wrote: > > 3) > > I think that you are completely omitting one of the key players from > this API. The Invocation. The goal of successful Session management is > that Invocation and Session should meet somewhere in the cluster for > the successful rendering/processing of a page/rpc/whatever. The > Invocation carries all the information that you may wish to a) > intercept and process elsewhere, b) pass onto the Session management > layer to aid in its decision making upon creation, retrieval and > invalidation of a Session. Depending on how responsibilities are split > between client container and Session manager, the session management > layer may actually want to modify the return values in this > Invocation - adding removing session cookies/attributes, changing ttls > upon this attribute, changing the value of this attribute or altering > other information within the Invocation that is used to integrate it > better with the Client at the other end of the wire. All these > interactions should be opaque to the client-container > (Jetty/TC/OpenEJB/...) and depend entirely on the implementation of > the Client (or e.g. Http loadbalancer) and the session management > layer. I think this generic Session API is trying to avoid getting into protocol specifics so it's main goal is to avoid defining a model for a Invocation. I do believe that it's goal that It exposes enough information such as where the session is located, so the protocol specific Session APIs can be built on top of it. Illustrations : > > 1). I don't think that the Location of a Session if of any relevance > to the Consumer. Jetty/TC/OpenEJB are simply interested in looking up > a Session and using it. A number of classes in > org.apache.geronimo.session talk in terms of Location. I see Location > as an implementation detail. WADI will have trouble mapping to some of > the assumptions that appear to be made in this part of the > API. e.g. Locator.getSessionLocation() is not an efficient thing to do > in WADI. It involves a round-trip to the owner of this section of the > Location Map. When WADI wants to move a Session it sends a message to > this node, which sends a message to the owner of the Session, which > sends a message containing the Session to the node that made the > request - 3 hops. This API would require a 4-hop trip - 1 rpc (2-hops) WADI could start caching that kind of location information and then it woul= d not need RPC to get the data. Seems like knowing the location of a session would be crucial in making a desicion to redirect, proxy, or move the session. to find the location and one (another 2 hops) to retrieve it. There is > actually a lot more detail involved here (another two hops are > involved in locking/unlocking etc) in which this API would create > further issue. Why bother to describe all implementations when the > Session consumer has no requirement ? > > 2). I'll call on the KISS principle here. I think that by exposing the > issues of colocation in the API, you are moving complexity from the > implementation into the API. I think the priority should be to keep > the API simple. At the creation of a Session the client container I think that every protocol is going to make session management decisionsdifferently. Not every protocol can do a redirect for example. They should be the ones in charge of deciding how to get the invocation and the session to meet. -- Regards, Hiram Snell Jonell Gospel Cornell Ginelle Edit... Ignore all Add to dictionary PRC PC RC RP Ric Edit... Ignore all Add to dictionary tls tels ttys Tl's til's Edit... Ignore all Add to dictionary Punjab Punjabi Edit... Ignore all Add to dictionary load balancer outbalance lovableness lordliness likableness Edit... Ignore all Add to dictionary generic Gerick Garrick Gerek Gerik Edit... Revert to "gereric" AP Is AP-Is Apia Apish AIs Edit... Ignore all Add to dictionary Punjab Punjabi Edit... Ignore all Add to dictionary (No suggestions) Edit... Ignore all Add to dictionary (No suggestions) Edit... Ignore all Add to dictionary PRC PC RC RP Ric Edit... Ignore all Add to dictionary decision deicing desiring design discoing Edit... Ignore all Add to dictionary co location co-location collocation coloration collocations Edit... Ignore all Add to dictionary management managements management's Edit... Revert to "managment" decisions sessions cessions session's delusions Edit... Revert to "dessions" ------=_Part_6139_33326047.1142262346754 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

On 3/9/06, Jules Gosnell <jules@co= redevelopers.net> wrote:
3)

I think that you are completely omitting one of the key players f= rom
this API. The Invocation. The goal of successful Session management = is
that Invocation and Session should meet somewhere in the cluster for
the successful rendering/processing of a page/ rpc/whatever. The
Invocation carries all the information that you= may wish to a)
intercept and process elsewhere, b) pass onto the Sessio= n management
layer to aid in its decision making upon creation, retrieva= l and
invalidation of a Session. Depending on how responsibilities are split<= br>between client container and Session manager, the session management
= layer may actually want to modify the return values in this
Invocation -= adding removing session cookies/attributes, changing=20 ttls
upon this attribute, changing the value of this attribute or= altering
other information within the Invocation that is used to integr= ate it
better with the Client at the other end of the wire. All these
interactions should be opaque to the client-container
(Jetty/TC/ OpenEJB/...) and depend entirely on the implementation of
the Cli= ent (or e.g. Http loadbalancer) and the session management
layer.
=
I think this generic Session API is trying to avoid getting into protocol specifi= cs so it's main goal is to avoid defining a model for a Invocation.  I= do believe that it's goal  that It exposes enough information such as= where the session is located, so the protocol specific Session=20 APIs can be built on top of it.
 

Illustrations :

1). I don't= think that the Location of a Session if of any relevance
to the Consumer. Jetty/TC/ OpenEJB are simply interested in looking up
a Session and using i= t. A number of classes in
org.apache.geronimo.session talk in terms of Location. I see Locatio= n
as an implementation detail. WADI will have trouble mapping to some of=
the assumptions that appear to be made in this part of the
API.=20 e.g. Locator.getSessionLocation() is not an efficient thing to do
in W= ADI. It involves a round-trip to the owner of this section of the
Locati= on Map. When WADI wants to move a Session it sends a message to
this nod= e, which sends a message to the owner of the Session, which
sends a message containing the Session to the node that made the
req= uest - 3 hops. This API would require a 4-hop trip - 1 rpc (2-hops)
 
WADI could start caching t= hat kind of location information and then it would not need RPC to get the = data.  Seems like knowing the location of a session would be crucial i= n making a=20 desicion to redirect, proxy, or move the session.

to find the location and one= (another 2 hops) to retrieve it. There is
actually a lot more detail involved here (another two hops are
invol= ved in locking/unlocking etc) in which this API would create
further iss= ue. Why bother to describe all implementations when the
Session consumer= has no requirement ?

2). I'll call on the KISS principle here. I think that by exposing = the
issues of colocation in the API, you are moving complexity from the
impleme= ntation into the API. I think the priority should be to keep
the API sim= ple. At the creation of a Session the client container

I think that every protocol is going to make session management decisions differently.  Not every protocol can do a redirect fo= r example.  They should be the ones in charge of deciding how to get t= he invocation and the session to meet. 

--
Reg= ards,
Hiram
Snell
Jonell
Gospel
Cornell
Ginelle
Edit...
Ignore all
Add to dictionary
PRC
PC
RC
RP
Ric
Edit...
Ignore all
Add to dictionary
tls
tels
ttys
Tl's
til's
Edit...
Ignore all
Add to dictionary
Punjab
Punjabi
Edit...
Ignore all
Add to dictionary
load balancer
outbalance
lovableness
lordliness
likableness
Edit...
Ignore all
Add to dictionary
generic
Gerick
Garrick
Gerek
Gerik
Edit...
Revert to "gereric"
AP Is
AP-Is
Apia
Apish
AIs
Edit...
Ignore all
Add to dictionary
Punjab
Punjabi
Edit...
Ignore all
Add to dictionary
(No suggestions)
Edit...
Ignore all
Add to dictionary
(No suggestions)
Edit...
Ignore all
Add to dictionary
PRC
PC
RC
RP
Ric
Edit...
Ignore all
Add to dictionary
decision
deicing
desiring
design
discoing
Edit...
Ignore all
Add to dictionary
co location
co-location
collocation
coloration
collocations
Edit...
Ignore all
Add to dictionary
management
managements
management's
Edit...
Revert to "managment"
decisions
sessions
cessions
session's
delusions
Edit...
Revert to "dessions"
------=_Part_6139_33326047.1142262346754--