Re: [wsrp][interfaces]: Portal Usage Scenario

[Michael Freedman <Michael.Freedman@oracle.com>]

Two potential reasons:
    a) in practice we find that the individuals given
the Admin role and those given the Page design role are distinct users
vs. being a pure subset.
    b) We have (and would like to continue to) provide
page design operations via the "usage interface".
   -Mike-

Alejandro Abdelnur wrote:

Mike,

I agree with (a) Administration and (c) End User level definitions as you are describing them.

I think that all (a) Administration functionality should be done outside of the 'usage interface'.

What is the rationale not to see (b) Page/Portal Designer as a subset of (a) Administration when from the portlet perspective it's just a further configuration of portlet settings ?

Regards.

Alejandro

Michael Freedman wrote:

Can you clarify what you mean by "Administrator"?  In our world we have (at
least) three levels:
     a) Administrator
     b) Page/Portal Designer
     c) End User

Your use of Administrator seems to map closest to our (a) Administrator.  [see
definitions below]. When others have talked about it I have mapped to (b)
Page/Portal Designer.  I can see how (a) might be done out of the "usage
interface".  Its less obvious to me the value to do (b) outside the "usage
interface".

Definitions:

The Administrator is responsible for registering/adding portlets to the portal.
The administrator can configure portlets (change those configuration settings
that are modifiable).  Changes made here effect all portlet instances created
here after.

The Page/Portal Designer is responsible for developing the initial structure of
the portal for a collection of end users.  In doing so the Page/Portal Designer
is capable of modifying portlet settings.  Portlet settings may effect either
portlet state or behaviors of a specific portlet instance (though its just as
easy to imagine that this instance is a template for future instances).
Commonly, these settings include the End user customization attributes allowing
the Page/Portal Designer to preset defaults for the End-Users.

End User is responsible for personalizing the Portal.  In doing so they are
capable of personalizing portlets.
   -Mike-

Alejandro Abdelnur wrote:

Tamari, Yossi wrote:

Hi Thomas,

I don't think that the fact the portal can set the portlet's properties
means that there can be no plug-and-play.
The Portlet can advertise its properties and their type (XML-Schema like) in
its meta-data, and the portal can use this meta-data to automatically
display a set-properties page. While this page can not be as customized as
the portlet generated page, it has the advantage of creating a uniform
set-properties look and feel throughout the portal.

I'm just saying both options have their merits, and we should regard both.

      Yossi.

I agree with Yossi. We should investigate/consider other alternatives.

This is somehow related to an issue I've brought up in the WSRP/security
conf call last week about "...separation of interfaces and roles for
administrative vs. non-administrative usage. ..."

I see some key problems on the approach we are heading to, where we do
not have a separate administration interface from the regular usage
interface. Administration and personalization are very different beasts.

Using a definition from a colleague, personalization of a component is
when a user customizes the behavior of the component for himself; while
administration is when a user customizes the behavior of the component
for one (other than her) or more users.

I see personalization being done through the usage interface, as most
portal frameworks -if not all- do it today.

I see as a possibility to do administration of portlets through
portlets, not the same portlet but a special administration portlet
provided by the WSRP service.

I have problems seeing administration functionality being done through
the usage interface of the same portlet is to be administered.

Personalization is about a given portlet instance for a given user.
Administration may have to deal with roles, groups, templates, etc.

In my opinion, it will be very hard to implement a portlet to do this
administration unless the portlet is knowledgeable of the WSRP service
configuration data model. A portlet knows about the business logic it
produces presentation logic for. A portlet knows about the
configuration/personalization parameters it needs. But a portlet does
not necessary know how the container hosting the portlet organizes and
stores the configuration or personalization parameters handled to the
portlets.

Another problems that I see are:

* The administration interface should allow an administration tool to be
built using portlets, but it must not impose additional requirements on
the administration framework.

* Administration should not require the administrator to put the portlet
in his portal page in order to administer it.

* It should be the responsibility of the WSRP service (or the portal),
but not of the portlet, to manage the details of delegated administration.

* Security of the usage and administration interface may be different.

* It's delegated to the portlet to decide if a user can do
administration or not.

* The usage interface may have different scalability requirements than
the administration interface.

Finally, there are different specifications that address management of
resources in distributed environments such as CIM, SMNP, JMX (Java
specific). Also, in OASIS there is a proposal for a Management Services
TC. We should investigate if any of them are suitable.

Regards.

Alejandro

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>