OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-interfaces message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wsrp-interfaces] Groups - Consumer_Defined_Hierarchies.htm ( formerlyCCPRelationships.htm) modified






Yossi,
I agree. The "type" notion I introduced is certainly not enaugh and I agree
that there may be mutliple root CCPs.
I also agree on your child definition.
We've talked a little bit about that last year and I felt that we agree
that if we want to solve these use cases we need a clone tree, i.e.
parent-child relationships.
I guess the answer to this may be twofold:
First, I guess the portlets will have to define some "config" specific data
which would apply to multiple users, in contrast to "edit" data which are
user specific.
This could be a good approach since only the portlet developer really
understands the specifics here.
So one approach might be to have mutliple "data" areas in the portlet (this
may come back to Scott's "config" vs "edit").
Second, since Cosumers do the clones they seem to be able to build such a
tree on their own (including multiple roots) and determine which portlets
will be affected by a change.
However on the Producer side portlets need to know their relationships,
too. Since a modification needs to be propageted somehow.
I think the only instace which can "build" the tree is the Consumer since
it knows the usage of the portlets. As said it also needs to know the
"shared" state areas which when change will affect all children.
I could imagine the following:
1. Consumer clones a POP (which defines it has some "config" state) and
marks the new CCP1 as a tree root (we need to talk about tree depths at
some time - for now a depth of 2 should be enaugh)
2. Consumer clones the root CCP1, needs to mark CCP2 as being a child of
CCP1
3. If someone changes "config" state at CCP1 it is propagated to the
children by whatever means (could be a shared data area anyways)
3. question: can the tree be traversed backwards, i.e. if the same "config"
state is modified on CCP2, should it also apply to CCP1?
I guess the question here is if we really need "trees" with all necessary
traversals, state propagation, etc. or are "groups" sufficient? I.e. there
would be a group state common to all portlets in that group, here CCP1 and
CCP2. The "config" state can be changed on any of these and would apply to
the whole group.

I guess the answer to that would lead us back to the use cases and to the
question what we we want to solve.

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:richard.jacob@de.ibm.com


                                                                           
             "Tamari, Yossi"                                               
             <yossi.tamari@sap                                             
             .com>                                                      To 
                                       interfaces                          
             07/25/2004 11:53          <wsrp-interfaces@lists.oasis-open.o 
             AM                        rg>                                 
                                                                        cc 
                                                                           
                                                                   Subject 
                                       RE: [wsrp-interfaces] Groups -      
                                       Consumer_Defined_Hierarchies.htm (  
                                       formerly CCPRelationships.htm)      
                                       modified                            
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Hi Richard,

The description and use case you give are very good, except that there can
be multiple "root" CCP that share the same POP but not the same config data
(for example in your use case it may be that one organization has different
SMTP servers in different locations).

This also brings to me the answer to Subbu's question "why can't this be
done with the existing API?" - Clone now gets a whole new meaning. Until
now clone always meant "new sibling". Now it can mean "new child". Since I
expect some consumers and producers will want to use the "sibling"
metaphor, and some the "child" one, there must be some way in the protocol
to indicate this.

             Yossi.

-----Original Message-----
From: Richard Jacob [mailto:richard.jacob@de.ibm.com]
Sent: Friday, July 23, 2004 4:18 PM
To: interfaces
Subject: RE: [wsrp-interfaces] Groups - Consumer_Defined_Hierarchies.htm
(formerly CCPRelationships.htm) modified





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:richard.jacob@de.ibm.com



             "Coco,
             Christopher"
             <Christopher.Coco                                          To
             @vignette.com>            "Subbu Allamaraju" <subbu@bea.com>
                                                                        cc
             07/22/2004 07:11          "interfaces"
             PM                        <wsrp-interfaces@lists.oasis-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:subbu@bea.com]
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:subbu@bea.com]
> 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:yossi.tamari@sap.com]
>  > 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:Christopher.Coco@vignette.com]
>  > Sent: Thursday, July 22, 2004 7:43 PM
>  > To: Subbu Allamaraju; wsrp-interfaces@lists.oasis-open.org
>  > 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:subbu@bea.com]
>  > Sent: Thursday, July 22, 2004 7:01 AM
>  > To: wsrp-interfaces@lists.oasis-open.org
>  > 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
>  >
>  > scott.goldstein@vignette.com wrote:
>  >
>  >  > Information about the document Consumer_Defined_Hierarchies.htm
>  >  > (formerly CCPRelationships.htm) has been modified by Scott
Goldstein
>  >  > (scott.goldstein@vignette.com).
>  >  >
>  >  > 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.
>  >  >
>  >  >
>  >
>






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]