wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp] NavState vs. Interaction State or what is the purpose ofinteraction state?
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp <wsrp@lists.oasis-open.org>
- Date: Wed, 31 May 2006 14:06:49 -0400
We did add requestVerb to ClientData
which gM(), gR() and pbia() all receive.
As to the cacheability of gR() responses,
section 6.3.1 says that the returned cacheControl determines how the Consumer
is to apply caching to the resource (much cleanly than we had for the http
proxying of resources in v1). Would a conformance statement in 6.3.1 make
this better address the scenario you raise?
Rich
Richard Jacob <richard.jacob@de.ibm.com>
05/31/06 10:58 AM
|
To
| Subbu Allamaraju <subbu@bea.com>
|
cc
| wsrp <wsrp@lists.oasis-open.org>
|
Subject
| Re: [wsrp] NavState vs. Interaction
State or what is the purpose of interaction state? |
|
Well, as my input to the pre F2F version to gR():
"46. 6.1.24 ResourceParams type
I would expect that Producer use ResourceParams as a proxying means (that's
the main purpose of why we introduced it) and thus will typically also
want
to generate a HTTP request to their back end servers.
Do we need more information to mimic the HTTP request here?
Examples especially when we're thinking about AJAX might be the HTTP verb
like POST, GET, and even PUT or DELETE.
Also do we want/need to distinguish between idempotent operations and
operation modifying state?
From the Consumer's perspective all getResource operation results seem
to
be cachable and idempotent. This might not necessarirly be true."
Again, what happens to cachability of gR() results if it can modify state?
One proposal I had quite a while ago is to have two operations
getResource() and modifyResource(). How can the Conumer know if gR() result
is cacheable or not?
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
WSRP Technical Lead
WSRP Standardization
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com
Subbu Allamaraju
<subbu@bea.com>
To
05/31/06 03:51 PM
wsrp <wsrp@lists.oasis-open.org>
cc
Subject
Re: [wsrp]
NavState vs. Interaction
State or
what is the purpose of
interaction
state?
> Portlets had a lot of flexibility already. Looking at this again from
a
> consistency point of view, I can see adding a resourceState field
and
> accompanying portlet url parameter.
I agree.
Subbu
> *Subbu Allamaraju <subbu@bea.com>*
>
> 05/30/06 06:51 PM
>
>
> To
> Michael Freedman <michael.freedman@oracle.com>
> cc
> wsrp <wsrp@lists.oasis-open.org>
> Subject
> Re: [wsrp] NavState vs. Interaction
State or what is the
purpose of
> interaction state?
>
>
>
>
>
>
>
>
> I raised a question about getResource not taking additional input
(like
> a resourceState as you suggest) sometime last year. The outcome of
the
> discussion was that that producer is responsible for generating
> resourceID to point to the state. IMO, that is not the cleanest solution
> since it would require the producer to manage the mapping somewhere,
or
> encode it in the navigationalState. But the later option seems
> inconsistent given the semantic difference between resources and markup.
> But that's what we have now.
>
> Subbu
>
> Michael Freedman wrote:
> > What is the significant benefit you see to distinguishing
between them
> > relative to building the url? Also, if you believe
it is significant
> > and the significance is tied to the model you define, why
doesn't
> > getResource take a resourceState field to carry additional
state
needed
> > to process getting the resource?
> > -Mike-
> >
> > Rich Thompson wrote:
> >>
> >> The model in the protocol is that navState is what
is required to
> >> properly render the portlet for the user. Interaction
state provides
> >> any additional state needed to process the action.
> >>
> >> My analogy to the web world distinguishes between state
sent on the
> >> post and what is passed on a redirect to a get request.
Often the
> >> state on the post is a superset of what is on the get
request.
Outside
> >> of the serialize/deserialize issues of getting these
on and off urls,
> >> I don't see why a web app would distinguish between
them internally.
> >> On the other hand, I do see significant benefits to
distinguish them
> >> relative to building the url and hence also within
the WSRP protocol.
> >>
> >> Rich
> >>
> >>
> >> *Michael Freedman <michael.freedman@oracle.com>*
> >>
> >> 05/30/06 04:38 PM
> >>
> >>
> >> To
> >>
Subbu Allamaraju <subbu@bea.com>
> >> cc
> >>
wsrp <wsrp@lists.oasis-open.org>
> >> Subject
> >>
Re: [wsrp] NavState vs. Interaction State or what
> is the purpose of
> >> interaction state?
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> See comments inline:
> >>
> >> Subbu Allamaraju wrote:
> >>
> >> > My interpretation is that nav state represents
outcome of action
> >> > processing, where as interaction state is usually
an input to the
> >> > action. It is not managed by the consumer beyond
the current
request.
> >> >
> >> > [MF] Your (first sentence) definition matches
what I saw as the
> >> > original intent before MarkupParams was passed
to the PBI. I don't
> >> > really understand your second (sentence) point:
navState must be
> >> > explicitly output from a PBI for the consumer
to continue to
maintain
> >> > it hance from a technical perspective there is
now difference as to
> >> > whether the inputs to PBI were interactionState
or navState -- the
> >> > operation still has to decide what values constitute
the new
navState
> >> > and respond.
> >> >
> >> > Another key (and probably more important) difference
is that
> >> > interaction state could be different between two
URLs generated by
a
> >> > portlet, but both URLs will most likely carry
the same nav state.
In
> >> > this case, I can't think of a way of mapping interaction
state as
> >> > navigational state.
> >> >
> >> > [MF] Again, from a PBI point of view NavState
is (now) both input
and
> >> > output, in addition navState can change during
the interaction
> >> > processing, this is a superset of what interaction
state does -- in
> >> > the end the developer is merely encoding state
into the ActionUrl
--
> >> > hence it shouldn't be problemmatic to encode both
PBI only state +
> >> > PBI/render state into navState. Are you
thinking that many
developers
> >> > end up modeling navState in explicit objects and
hence anything
that
> >> > isn't needed to represent render state would need
to come from a
> >> > different abstraction? If so, how common
is this in a web
developer
> >> > world where such state are usually seen as request
parameters that
are
> >> > then pushed into models/backing (managed) beans?
> >> >
> >> > Subbu
> >> >
> >> > Michael Freedman wrote:
> >> >
> >> >> Given the current state of the spec, I am
trying to figure out
what
> >> >> the purpose of interactionState is. Can
anyone help? My
> >> >> recollection is that originally interactionState
was the PBI
> >> >> equivalent of navigationalState (for getMarkup)
prior to us adding
> >> >> the "performance enhacement" that
passed PBI MarkupParams so
> >> >> action/render response could occur in a single
request. This no
> >> >> longer seems to be our intent as shown by
the URL samples in
section
> >> >> 10.2.1.9. I.e. the second example expresses
an actionURL with
both
> >> >> navigationalState and interactionState. What
is the new model? I
> >> >> can think of something like interactionState
holds those values
that
> >> >> augment the action processing while navigationalState
holds those
> >> >> values that augment the rendering process
-- but that seems pretty
> >> >> meaningless given that in most applications
state is state that
you
> >> >> compute with and render from. I.e. why
wouldn't developers merely
> >> >> represent all such state as NavigationalState
(particularly
because
> >> >> this form now has an opaque and non-opaque
portion)? Since
navState
> >> >> doesn't inherently carry forward at the end
of an action/event,
you
> >> >> must explicitly set it it seems to offer everything
interactionState
> >> >> does but in one object that spans all operations.
> >> >> -Mike-
> >> >>
> >> >>
---------------------------------------------------------------------
> >> >> To unsubscribe from this mail list, you must
leave the OASIS TC
that
> >> >> generates this mail. You may a link
to this group and all your
TCs
> >> >> in OASIS
> >> >> at:
> >> >>
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >> >
> >> >
> >> >
> _______________________________________________________________________
> >> > Notice: This email message, together with
any attachments, may
> contain
> >> > information of BEA Systems, Inc.,
its subsidiaries and
> affiliated
> >> > entities, that may be confidential, proprietary,
copyrighted
> and/or
> >> > legally privileged, and is intended solely for
the use of the
> individual
> >> > or entity named in this message. If you are not
the intended
> recipient,
> >> > and have received this message in error, please
immediately return
> this
> >> > by email and then delete it.
> >> >
> >> >
---------------------------------------------------------------------
> >> > To unsubscribe from this mail list, you must leave
the OASIS TC
that
> >> > generates this mail. You may a link to this
group and all your TCs
in
> >> > OASIS
> >> > at:
> >> >
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe from this mail list, you must leave
the OASIS TC that
> >> generates this mail. You may a link to this group
and all your TCs
in
> >> OASIS
> >> at:
> >>
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe from this mail list, you must leave
the OASIS TC that
> >> generates this mail. You may a link to this group and
all your TCs in
> >> OASIS at:
> >>
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
> _______________________________________________________________________
> Notice: This email message, together with any attachments, may
contain
> information of BEA Systems, Inc., its subsidiaries
and affiliated
> entities, that may be confidential, proprietary, copyrighted
and/or
> legally privileged, and is intended solely for the use of the individual
> or entity named in this message. If you are not the intended recipient,
> and have received this message in error, please immediately return
this
> by email and then delete it.
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. You may a link to this group and all your
TCs in
OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
> ---------------------------------------------------------------------
To
> unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. You may a link to this group and all your TCs
in
> OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
_______________________________________________________________________
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries
and affiliated
entities, that may be confidential, proprietary, copyrighted
and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs
in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs
in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]