Title: RE: [wsrp-interfaces] Groups - Consumer_Defined_Hierarchies.htm
(formerlyCCPRelationships.htm) modified
I see access control of property
modifications being solved through our user identity propagation mechanisms. The
Producer can simply assert the current users role to determine if they can
modify a particular property. Is there a reason this would not be
sufficient?
I do see a use case for sharing configuration
state across portlet boundaries within a portlet application. I’m
not sure, however, that it’s a particular use case that I would want to
solve within this feature proposal. How do others feel?
Scott
From: Andre
Kramer [mailto:]
Sent: Monday, July 26, 2004 7:34
AM
To: interfaces
Subject: RE: [wsrp-interfaces] Groups -
Consumer_Defined_Hierarchies.htm (formerlyCCPRelationships.htm) modified
On the config access
control suggestion, I was purposely being neutral on what scope the admin's
modifications would have. Hierarchy related changes are already proposed, but
administration "delegation" (i.e. for all users I manage) and Portlet
application scope (i.e. for all users of that application) seem very valid
re-occurring use cases to me.
We have
"groupID"s for supporting JSR 168 in WSRP 1.0 but this still does not
seem well matched to such scopes. At the risk of confounding two 2.0 feature
discussions (sorry): We could leverage registrations and the newHandle =
copyPortlet(portletHandle, fromRegistrationHandle, toRegistrationHandle) to
scope the "sharing" of property modifications. Rather than building
in extra support (formal contracts) for shared customizations, this could
enable shared properties to be updated in a registration (per-Registration -
but never across registrations. And non-shared properties are just
per-Portlet/per-Registration). This does not state how properties are actually
shared within a registration (can have more complex inter-clone relationships
within registrations) or who may update shared properties, but this could
enable some very typical use cases: e.g admin changes settings for a Portlet
application. Here, the consumer would only allow an authenticated/authorized
Admin to effect such (audited) changes. And the fact that only producer admin is
allowed to change POPs is reflected by an implicit top level (default) scope.
Again, I'm just thinking
aloud, ahead of next week's f2f.
Regards,
Andre
From: Goldstein, Scott
[mailto:]
Sent: 24 July 2004 19:44
To: interfaces
Subject: RE: [wsrp-interfaces] Groups -
Consumer_Defined_Hierarchies.htm (formerlyCCPRelationships.htm) modified
I'm a little behind in
the discussion, so I'm going to try to cover all comments that I've seen thus
far. Let me know if I miss anything.
First, Andre brought up
the notion of portlet properties. The feature proposal, as it stands,
talks about hierarchies in relation to portlet state. This was the use
case we had, and, therefore, that's what I modeled the feature proposal around.
However, when you start discussing CCP hierarchies, portlet properties and
inheritance of portlet properties is a feature which obviously must be
considered. In order to validate such a feature, we would have to come up
with an associated use case. Personally, I think you can adapt the one I
provided for portlet state fairly easy. The consumer could generate a
screen within an administration view to set portlet properties for a
"parent" CCP. These values could then be inherited to "child"
CCP's created as a result of additional end user customization of the
portlet. If necessary, the administrator could return to the
administration screen to change the value of the portlet properties on the
parent and affect all of the "child" CCPs due to the inheritance.
Secondly, Rich brought up
the notion of declaring a portlet property to be final or config level.
This involves the situation in which properties can be set on a particular
"parent" CCP, but not on child "CCPs". To understand
the use case, I would ask who can determine whether a particular portlet
property should be final or not? To answer this question, I think you
have to consider the following actors - Consumer, Producer, Consumer
Administration, Producer Administration, and Portlet Developer.
1. Consumer - Since a Consumer doesn't really understand the purpose
of a particular portlet property, it really can't make a determination whether
a particular portlet property is an administrative one or not. Therefore,
I would suggest that the Consumer isn't able to make this determination.
2. Consumer Administrator - In this case, the Consumer would
autogenerate a screen within an administrative context for setting portlet
properties on the "parent" CCP. Within the autogenerated
screen, next to each property, would be a check box to set whether or not end
users could override or customize the value of the property. By selecting
the check box, the portlet property can be set to be final, not allowing the
property to be set on "child" CCPs and, therefore, not allowing end
users to customize it.
3. Producer - I think this is the same case as the Consumer. It
doesn't understand the purpose of portlet properties and, therefore, can't make
a determination whether or not a property should be final.
4. Portlet Developers - When developing a portlet for general
consumption, a portlet developer wouldn't want to limit functionality. In
other words, the ultimate goal would be to make the portlet as configurable as
possible, allowing it to be reused in multiple environments with varied
requirements for access control. I do imagine a scenario in which they
may want to suggest a default behavior based on the function of the portlet,
but they wouldn't want to make the final determination.
5. Producer Administrator - If a particular property affected a back
end system or required knowledge of a back end system, I could see the case in
which you would want, as a Producer Administrator, to limit access to those
properties to admin users only. Therefore, it would make sense that a Producer
Administrator would want to declared properties final. However, I would
argue that it would be difficult to determine on which CCP to declared the
property final. It depends on the Consumer implementation and how CCPs
are used. What you could do, I suppose, is declare a property to be final
within a POP as a suggestion to the Consumer. However, this really
wouldn't provide any hard control. The question would be, is there a use
case for having the ability to provide only a suggestion?
Given the above, I can
see #2 being a possible reason for having the ability to set a portlet property
to be final. #5 is also a possibility, but questionable. Rich and
Yossi - You both seems to be interested in this feature. What are your
thoughts on the above? Do you agree? Would your use cases fall into
#2 and #5 or is there a scenario that I'm missing?
Thirdly, the question
came up as to why you would want to declare a CONFIG mode within the WSRP
specification. This is related to the difference between portlet state
and portlet properties. In item #2 above, the consumer provides a check
box to declare what properties an end user should be able to edit. It's
possible, however, for usability reasons, that an autogenerated screen isn't
ideal for configuring a particular portion of portlet state. For
instance, in the use case I've given, the config mode of the portlet generates
an expandable folder tree representing the directory structure of the content
repository. I can't think of a standard XSD data type which would lead a
consumer to autogenerate such a tree, much less one with the exact contents of
a back end repository. Therefore, it makes more sense for the portlet to
generate the screen and set the state through a pbia(). However, as a
portlet developer, ideally you still want to provide the flexibility to the
Consumer Administrator to declare what an end user should/shouldn't be able to
customize. This is where CONFIG mode comes in. It would contain a
checkbox for configuring whether or not end users could change the
folder. You then have an option of, near the checkbox, rendering the
folder tree allowing the admin to specify a default, or rendering this tree
within another mode which correlates to the jsr 168 EDIT_DEFAULTS mode.
I would also argue that,
due to lack of time or prior knowledge of the deployment environment (company
intranet), a portlet developer would decide to simply not provide a checkbox.
In other words, they would make the decision that selecting a content
repository folder for the portlet is purely an admin function that end users
shouldn't be exposed to. They can achieve this, by only displaying the
folder tree within a CONFIG mode.
A final reason would
simply be interoperability with JSR 168 portlets. Considering that JSR 168
is a large source of the portlets to be produced, it makes sense to try to
align as much as possible with this specification.
Fourthly, Subbu brought
up the fact that a Producer could implement hierarchies on it's own, without
the use of the protocol. I would argue that this isn't sufficient.
First, since a Consumer could never know if a producer provides this
functionality, it would never predict when property/state inheritance would
occur. Secondly, I would argue that it's the Consumer implementation/feature
set that determines if properties/state should be inherited or not. Where
one consumer would desire the inheritance behavior, another might not.
Therefore, you need support in the protocol for the consumer to request that
inheritance be utilized.
Lastly, Andre brought up
the notion of using access control for authorization rather than a config
mode. The issue I see with this, is that config mode is more than simply
the properties which only an admin can see. It also provides a mean of
setting portlet state which applies to all users. It just happens to be
the case that, in most if not all scenarios, the responsibility of setting
state for all users is given to an administrator.
I think that covers all
of the comments which I saw. Some of this information probably need to be
rolled into the use cases in the feature proposal. Before doing that,
though, I'll wait to see what everyone agrees/disagrees with.
Scott
From: Andre
Kramer [mailto:]
Sent: Friday, July 23, 2004 7:11
AM
To: interfaces
Subject: RE: [wsrp-interfaces] Groups -
Consumer_Defined_Hierarchies.htm (formerlyCCPRelationships.htm) modified
Just an attempt at an observation: When we think of
this ("config") as a mode it seems never to be very compelling but
when we view it as something an admin does (versus a normal user) we tend to
see a valid use case.
Maybe re-casting this in terms of "access
control" or "authorization" would be an approach? The portlet
would declare and enforce edit authorization based on user / role
authentications. The consumer would need meta-data (WS Policy) in order to also
act as a policy enforcement point.
Here "config" is not so much a mode but a
special role that we recognize?
Regards,
Andre
-----Original Message-----
From: Subbu Allamaraju [mailto:]
Sent: 23 July 2004 14:43
To: interfaces
Subject: Re: [wsrp-interfaces] Groups -
Consumer_Defined_Hierarchies.htm (formerlyCCPRelationships.htm) modified
I think that's the way JSR168 tried to define this
mode. However, is
there a reason to think that such
configuration cannot be addressed by
the current portlet management
interface?
Here is an example. Assume that a CCP1 and CCP2 are
cloned from CC0, and
CCP1 and CCP2 are hierarchically
related to CC0 (the relationship is
producer-implementation specific
and is not exposed in the protocol). To
configure this portlet, the admin
sends setPortletProperties request for
CC0, where as users send setPortletProperties
request for CCP1 and CCP2.
The producer, in some
implementation specific way, propagates data
changes from CCP0 to CCP1 and CCP2.
In this case, both the hierarchies and configuration
are not exposed in
the protocol. Here, I considered
the parent to be a CCP to be consistent
with the current
setPortlteProperties operation.
Extending this argument further, I think such
configuration belongs to
the portlet maangement interface
and not the markup interface. With
markup interface, a consumer can
allow/disallow a producer/portlet to
change its state, but cannot force
persistent state changes. The portlet
management interface, on the
otherhand, allows for *explicit* state changes.
Christopher, could you elaborate on the motivation (or
specific issues
faced in implementation) for
exposing hierarchies in the protocol?
Regards,
Subbu
Richard Jacob wrote:
>
>
>
>
> I think what is discussed in
the thread is basically the question if there
> is some kind of
"shared" state which applies to all portlets (of the same
> class, i.e. are cloned from
the same POP) - Chris named it "config" state.
> If I understood correctly the
proposal could be to have one area of the
> portlet state which has the
explicit notion of configuration data in
> contrast to the customization
data.
> One example:
> A mail portlet could have
configuration data like the smtp and imap server
> FQDNs which can be changed by
the admin only (Chris referred to the
> "config" mode here).
> Whereas customization data would
be the email address or login name of each
> individual user, i.e. user's
could do customization to that (for example in
> the "edit" mode).
>
> Mit freundlichen Gruessen /
best regards,
>
>
Richard Jacob
> ______________________________________________________
> IBM Lab Boeblingen, Germany
> Dept.8288, WebSphere Portal
Server Development
> WSRP Standardization Technical
Lead
> Phone: ++49 7031 16-3469
- Fax: ++49 7031 16-4888
> Email: mailto:
>
>
>
>
"Coco,
>
Christopher"
>
<Christopher.Coco
To
>
@vignette.com>
"Subbu Allamaraju" <>
>
cc
>
07/22/2004 07:11 "interfaces"
>
PM
<-open.o
>
rg>
>
Subject
>
RE: [wsrp-interfaces] Groups
-
>
Consumer_Defined_Hierarchies.htm
>
(formerly CCPRelationships.htm)
>
modified
>
>
>
>
>
>
>
>
>
>
> Config state changes would
only be an explicit setting of state in the
> 'config mode'. I know that the
end user can change end-user state during
> any interaction with the
portlet, but I was trying to draw a parallel to
> the case when end-user state
is explicitly set in the edit mode.
>
> thanks,
> Christopher
>
> -----Original Message-----
> From: Subbu Allamaraju [mailto:]
> Sent: Thursday, July 22, 2004
10:10 AM
> Cc: interfaces
> Subject: Re: [wsrp-interfaces] Groups -
Consumer_Defined_Hierarchies.htm
> (formerly
CCPRelationships.htm) modified
>
>
> Coco, Christopher wrote:
>
> > Yes the edit mode
is not required. I don't think thats the point. The
> > point is, if the
edit mode is supported, its purpose is for
> configuration
> > of the portlet. No?
>
> Even if the edit mode is
supported, the portlet can do anything. We have
> some suggestions in the spec,
but don't require that edit mode to be
> used for state changes.
>
> Subbu
>
>
> >
> > Christopher
> >
> > -----Original
Message-----
> > From: Subbu
Allamaraju [mailto:]
> > Sent: Thursday,
July 22, 2004 10:06 AM
> > To: interfaces
> > Subject: Re: [wsrp-interfaces] Groups -
Consumer_Defined_Hierarchies.htm
> > (formerly
CCPRelationships.htm) modified
> >
> >
> > Christopher,
> >
> > The spec does not
require portlets to offer a UI for editing state in
> > the edit mode, so
the consumer cannot expect that. I think that's the
> > point Yossi was
trying to make as well.
> >
> > Subbu
> >
> > Coco, Christopher
wrote:
> >
> > > True,
the state of a Portlet can change at any point. What I was
> trying
> > > to get
at is
> > > the edit
mode is where edit state can be explicitly set by an
> end-user.
> > > And
similarily,
> > > a config
mode would be where config state can be explicitly set by an
> > > admin
(per se).
> > >
> > >
Christopher
> > >
> > >
-----Original Message-----
> > > From: Tamari, Yossi [mailto:]
> > > Sent:
Thursday, July 22, 2004 9:57 AM
> > > To: interfaces
> > > Subject:
RE: [wsrp-interfaces] Groups -
>
Consumer_Defined_Hierarchies.htm
> > >
(formerly CCPRelationships.htm) modified
> > >
> > >
> > > Hi
Christopher,
> > >
> > > While I
agree with the general direction you are suggesting, it is
> true
> > > that a
portlet can change its (persistent) state as a result of any
> > >
interaction, regardless of the mode. The modes (like the window
> states)
> > > are
really more of UI concepts, where edit mode is expected to be
> a UI
> > > for
"configuring/personalizing" a portlet, but not necessarily the
> only
> > > time
when that can be done.
> > >
> >
> Yossi.
> > >
> > > -----Original
Message-----
> > > From: Coco, Christopher [mailto:]
> > > Sent:
Thursday, July 22, 2004 7:43 PM
> > > To:
Subbu Allamaraju;
> > > Subject:
RE: [wsrp-interfaces] Groups -
>
Consumer_Defined_Hierarchies.htm
> > >
(formerly CCPRelationships.htm) modified
> > >
> > > Its more
a question of portlet state than portlet properties. When
> > > parent
state
> > > is
updated for a portlet with 'child' clones, how are those changes
> > >
propagated
> > > to the
clones, if at all?
> > >
> > > The idea
behind the 'config' mode is that a consumer needs a mode in
> > which
> > > it knows
that it should send a 'shared' state (config state for lack
> > of a
> > > better
term) to the producer (for consumer-stored state), or a way
> > for the
> > > producer
to know to access the 'shared' (config state) (for
> > producer-stored
> > > state).
> > >
> > > I'm not
sure what you mean when you say that a consumer cannot assume
> > that
> > > it can
use a given mode to edit a portlet's properties. I would
> disagree
> > > with
this statement. What is the point of the current edit mode?
> Section
> > > 6.8.2 in
the spec specifically says that this mode is for an end-user
> to
> > >
customize the portlet state.
> > >
> > > As to
what properties are config versus edit, its completely up to
> the
> > >
Producer, as the state is opaque to the consumer. I don't think we
> > > have to
try to provide a mechanism for this. Yet, only a way to allow
> > > the
consumer to access config state of a portlet versus only end-user
> > > edit
state. Where config state again is state that is either
> inherited
> > > from a
parent portlet, or passed to a child.
> > >
> > >
Christopher
> > >
> > >
Christopher Coco
> > > Senior
Software Engineer
> > > Vignette
Builder
> > > p.
415.995.3534 | f. 415.975.9801
> > >
> > >
Vignette's software and expertise help organizations harness
> > > the
power of information and the Web to deliver measurable
> > >
improvements in business efficiency. Vignette is the efficiency
> > > expert.
Visit http://www.vignette.com/
to learn more.
> > >
> > >
> > >
> > >
-----Original Message-----
> > > From:
Subbu Allamaraju [mailto:]
> > > Sent: Thursday,
July 22, 2004 7:01 AM
> > > To:
> > > Subject:
Re: [wsrp-interfaces] Groups -
>
Consumer_Defined_Hierarchies.htm
> > >
(formerly CCPRelationships.htm) modified
> > >
> > >
> > > Since
portlets can modify properties in any mode and are not limited
> to
> > >
edit/config mode, can you elaborate on why it is important to
> > >
standardize a new mode called config?
> > >
> > >
Moreover, the consumer cannot assume that it can use a given mode
> (with
> > >
getMarkup and pbia) to edit portlet's properties.
> > >
> > > I
remember we had some long debate in the JSR168 EG, and dropped it
> for
> > > lack of
sufficient motivation.
> > >
> > > Subbu
> > >
> > >
wrote:
> > >
> > >
> Information about the document Consumer_Defined_Hierarchies.htm
> > >
> (formerly CCPRelationships.htm) has been modified by Scott
> Goldstein
> > >
> ().
> > >
>
> > >
> Document Description:
> > >
> First draft of feature proposal for Consumer Defined Hierarchies
> > >
>
> > >
> Download Document:
> > >
>
> > >
> >
> http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/download.php/7862/Consumer_Defined_Hierarchies.htm
>
>
> >
> > >
> > >
>
> > >
>
> > >
> View Document Details:
> > >
>
> > >
> >
> http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/document.php?document_id=7862
>
>
> >
> > >
> > >
>
> > >
>
> > >
>
> > >
> PLEASE NOTE: If the above links do not work for you, your email
> > >
> application
> > >
> may be breaking the link into two pieces. You may be able to copy
> > and
> > >
> paste
> > >
> the entire link address into the address field of your web
> browser.
> > >
>
> > >
>
> > >
> >
>
>
>
