wsrp-interop message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp-interop] cloneBeforeWrite when using ProducerOfferedPortlets
- From: Michael Freedman <Michael.Freedman@oracle.com>
- To: Rich Thompson <richt2@us.ibm.com>
- Date: Tue, 01 Jul 2003 16:04:29 -0700
Title:
Rich,
The level of independence you describe doesn't seem right/consistent to
me. I would prefer [thought] this field answered the question "which portlets
in this producer are clonable"? I don't think there is value to answering
the question "is pre-cloning this portlet an effective implementation strategy"?
Using the field to answer the first question is interesting because there
is no other way to determine this information. A consumer can figure whether
no portlets in the producer are clonable if the producer doesn't expose the
portlet management interface. However, unless we use this field it can't
determine if/which portlets in this producer can be cloned when the portlet
management interface is supported. This is interesting meta data that allows
a consumer to make implementation decisions. On the other hand if a consumer
must assume all portlets in a producer are clonable unless the associated
port isn't available, using this field to indicate that pre-cloning is/isn't
an effective implementation strategy is of little use. Pre-cloning isn't
more efficient -- clone on demand as a by product is always the most efficient.
So I see little value in including a [confusing] optimization flag that
says "go ahead an use the less efficient implementation even though you have
to support the more efficient one anyway". However, I can see some value
for my interpretation in those situations where clone on demand isn't an
option -- i.e. the portlet doesn't receive an action. The most specific
one being when the portlet is added to the portlet repository in the Portal
however you can even view adding a portlet to a page as an example. These
are "portal events" that don't correspond to underlying portlet calls/actions.
If the consumer knows the answer to the question "which portlets are clonable"
it can make implementation choices to always clone [those that are clonable]
when these events occur.
So my preference at this point is to either drop hasUserSpecificState because
its misleading and has little value or to modify its meaning to indicate
this portlet is clonable.
-Mike-
Rich Thompson wrote:
1. The hasUserSpecificState flag is independent
of whether or not clones are allowed. It simply states to the Consumer that
the portlet is going to store user specific state so that the Consumer can
clone the portlet before the first usage rather than receiving a clone back
on the first interaction. This flag was added due to the thinking that many
portlets would use a shared customization rather than user specific persistent
state. This becomes easier to manage if the number of clones is not increased
simply because a new user has registered with the Consumer.
2. I did not mean to imply the Producer
choosing to clone outside of portletStateChange="cloneBeforeWrite" (or a
clonePortlet() invocation), but do see how that could have been read into
my comments. I think the spec does limit the Producer to these two times
for when it may clone a portlet.
Rich Thompson
|
David Ward <david.ward@oracle.com>
06/30/2003 09:30 AM
|
To: Rich Thompson/Watson/IBM@IBMUS
cc: wsrp-interop@lists.oasis-open.org
Subject: Re: [wsrp-interop]
cloneBeforeWrite when using ProducerOfferedPortlets |
Yes so hasUserSpecificState = true => allow user specific
clones
does hasUserSpecificState = false => don't allow user specific clones?
If not, then this flag seems rather pointless, as you still seem to have the
possiblity of user-specific clones being created (so you may as well clone
the portlet on addition to the page all the time to prevent cache invalidations
in the future).
Are you also saying you would expect the producer to clone the POP even when
portletStateChange != cloneBeforeWrite? This makes the "readWrite" and "cloneBeforeWrite"
values sound equivalent.
Dave
Rich Thompson wrote:
The purpose of this flag (has UserSpecificState) is for those cases where
a portlet always has state specific to the user (e.g. an email portlet). It
is purely an optimization allowing the Consumer to clone the portlet for
the user on first view of a page containing it.
I would agree that using a value of cloneBeforeWrite for portletStateChange
(the new name) would be better when using POPs. There was some discussion
about whether this type of case should have its own fault message (CloneRequired),
but the decision was that it would be rare enough that OperationFailed or
PortletStateChangeRequired would be suffice.
I would note that the one down side of throwing the PortletStateChangeRequired
fault rather than cloning the POP is that the Consumer is unable to associate
the cloned portlet with any current session while the Producer can do such
a change while doing the clone (one of the big advantages of the clone-on-write
semantics).
Rich Thompson
OASIS WSRP TC Chair
Interaction Middleware and Standards for Portal Server
IBM T.J. Watson Research Center / Yorktown Heights, NY
Phone: (914) 945-3225 email: richt2@us.ibm.com
Shouldn't you be setting state change to "cloneBeforeWrite" in this case?
As far as I understand, the producer-offered entities are read-only.
I still have questions about the meaning of hasUserSpecificState from Andre's
testing. Does hasUserSpecificState=false mean the consumer should never have
to call cloneEntity() or send "cloneBeforeWrite"? If not, then what is the
purpose of this flag?
Andre's portlets are returning hasUserSpecificState=false, even though they
expect to be able to update state and hence clone new copies of the producer
offered entity.
Regards
Dave
Richard Jacob wrote:
Hi,
the Oracle producer throws a StateChangeRequiredFault if our consumer uses
a producer offered portlet (POP) and wants to change the persistent state
in edit mode of portlet E:0:default for example.
We have the InteractionParams.stateChange set to "readwrite" allowing the
producer to write.
I think the flag hasUserSpecificState in PortletDescription encourages the
consumer to clone, but it is not required to clone.
I think if a consumer using a POP allows the portlet to change its state,
the producer should perform a clone before write here.
The spec says for the PortletStateChangeRequiredFault: Used when a Portlet
needs to modify its persistent state, but has been prevented from doing so.
So my understanding is that this fault should only be thrown if the
consumer indicates "readonly" to the portlet but the portlet needs to
change its persistent state on an action.
If we interpreted the flag hasUserSpecificState=true as the requirement to
clone, producers not exposing the PortletManagement interface could never
have portlets that change their persistent state.
What do people think?
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com
You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/leave_workgroup.php
--
|
David Ward
Principal Software Engineer
Oracle Portal
|
Oracle European Development Centre
520 Oracle Parkway
Thames Valley Park
Reading
Berkshire RG6 1RA
UK |
|
--
|
David Ward
Principal Software Engineer
Oracle Portal
|
Oracle European Development Centre
520 Oracle Parkway
Thames Valley Park
Reading
Berkshire RG6 1RA
UK |
|
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]