My reply may not have been clear on this, I was not referring
to
individuals when I've said that (b) is a subset of
(a), I was referring
to the levels. Looking at the
definition of (b), from the portlet
perspective, (b)
level is a subset of (a) level.
I have concerns on putting this as a requirement. As I've
written
yesterday, a portal could definitely leverage
a portal framework for its
administration (and
Page/Portal Designer) but I don't like that being
imposed.
Also, I do not like the idea of a portlet being responsible
for its own
administration as this could include
delegated administration and it
would the portlet, not
its context, the one deciding what a given
administrator can do.
I'm more comfortable with the idea of providing metadata
together with
the portlet.
The metadata approach does not preclude a WSRP producer to
offer
administration of application portlets through
WSRP-producer portlets
that process the metadata and
create the proper content. This would
allow a WSRP
producer to use the 'usage interface' for administration
but it would be done using WSRP producer specific administration
portlets different from the application portlets. And
it would not
require to do this through a
portlet.
Regards.
Alejandro
Michael Freedman wrote:
> 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>
>>>>
>>>
>>>
>>>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the
subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>