Thomas,
See my comments below
David
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of [EMAIL PROTECTED]
> Sent: Friday, November 17, 2000 5:03 AM
> To: JetSpeed
> Subject: Re: Profiler
>
>
>
>
>
> We have implemented a custom user profiler that provides multi-page
> capability that we use to support multiple devices per user. It returns a
> PSML depending on the preferred MIME type of the capability
> associated with
> a request.
>
> To do this, we use a directory structure like this:
>
> \userid1\default.psml
> \userid1\default_wml.psml
> \userid1\default_voicexml.psml
> ...
>
> \userid2\default.psml
> \userid2\default_wml.psml
> \userid2\page1.psml
> \userid2\page2.psml
> ...
>
> All users have dafault pages that are shown when no explicit page name is
> provided in a request. Multiple default pages for different devices may
> exist. If a page name comes with the request, the user's page that matches
> the name is returned.
>
> Would that fit with the upcoming Profiler proposal ?
>
The Profiler is a service to abstract the management of target URLs for a
portal markup resource (PSML resource). The Profiler is applied to each
request, and it maps requests to PSML resources. Since each implementation
of a profiler may be different, we are providing the interfaces to the
service, and we will also provide a default implementation.
Starting with a request, the Profiler and Capability Map look at the
request, the Profiler will take the 'user' parameter (sometimes a sessionid
that maps to a user), the CapabilityMap will look at http headers
(eventually W3 CC/PP RDF descriptions - see
http://www.w3.org/TR/NOTE-CCPP/ )and together they build the target resource
URL.
The function of the ProfilerService is to build the target resource URL per
request based on request parameters which are also translated by the
CapabilityMap. The ProfilerService also manages accessing these resources,
and how that is done is up to the implementation of the service. Each
ProfilerService implementation will differ in how it stores PSML i.e. in
LDAP servers, WebDAV, databases....
I believe this PSML resource should be materialised as a 'Profile' object.
It would be interesting if the Profile's contents (Controls, Controllers,
Portlets) were also first-class persistence-capable objects, so that
Customizers could store changes to one portlet ref instead of re-writing the
entire psml tree. On the other hand, this may be overkill. Im not sure yet.
The 'directory structure' in your example above may be perfectly fine for
your implementation of a ProfilerService. The proposal defines a default
implementation of a Profiler, and it is file-based.
I see it a little different for the default, but Im open to suggestions. I
am basically continuing with Raphael's initial implementation along with the
new concept of 'roles', so that you have:
-- A root path. The root path is stored in JR.P in the psml.base.username
property.
-- All other paths to resources are relative from the root.
-- There are two subpaths under the root
-- users
-- roles
-- each user, role is further broken down by mediatype as defined in the
registry
these media types then map to a capabilityMap entries which defines the
mime type, also defined in the registry
So here is an example tree:
{root}
users
{default}
html
default.psml
Thomas
html
default.psml
page1.psml
wml
default.psml
David
html
default.psml
roles
Contributors
html
default.psml
page1.psml
wml
default.psml
SeniorSystemsArchitects
uml
default.psml
An incoming request from an html browser of:
http://www.jetspeed.biz/content/servlet/jetspeed
would map to the resource path, generated by the default Profiler as
{root}/users/{default}/html/default.psml
Your example shows different resources per user. I think this is valuable
and I will incorporate it in the proposal.
This non-default resource must be specified into the request.
Do you have a specific way to do this?
Or are we to use one of the Turbine components (page/screen/action} such as:
http://www.jetspeed.biz/content/servlet/jetspeed/screen/page1/
-----
Roles
-----
I would like to introduce the concept of Profile Roles.
UseCase:
When a user does not have their own specific PSML.
I am now working with a client with 40,000 employees.
At first, everyone will have default resources based on their department.
A ProfilerService provides this mapping.
For the default implementation, the mapping is stored in the registry under
the Profiler section.
<profile-registry>
<role-map name="SeniorSystemArchitects">
<user>Jon</user>
<user>Raphael</user>
</role-map>
...
A user shouldn't be defined in more than one role.
-------
Caching
-------
The default Profiler would also make use of the
JetspeedDiskCache/JetspeedResourceManagementService or whatever its being
called (ive been trying to follow your caching thread). This way the psml
resource (Profile object) can be cached in memory, which will be useful for
role-based resources, and they can expire when the session ends for a user,
or when all sessions end for a role.
------------
PortletsRefs
------------
In conversations with Marcus and Vedran, they had some interesting
experiences with handling requests to a specific portlet, and managing the
state of the portlet as the user sub-navigates through that portlet.
Requests to specific portlets are different from requests for an entire
portal resource, but in the end, the whole content must be regenerated
anyway, so it always comes back to the PSML resource.
Each portlet had to manage its own state, and I imagine it had to do so for
each user accessing a portlet which is shared across multiple psml
configurations. This leads to the question:
Why is it that a portlet is only instantiated once and then cached/shared
across all profiles?
I'd like to propose that portlet refs should have their instantiation and
lifetime declaritively controlled like
beans in JSP that can have scope <page/request/session/application>. The
scope is applied per Profile.
( Please feel free to shoot holes in this idea. Its fairly new )
A portlet's init params in a PSML are loaded via the Profiler.
TODO: how are the init params passed to each portlet for each PSML in
regards to scoping.
TODO: better describe portlet scoping.
What else...
-- The ProfilerService is a Turbine service and is specified in the turbine
properties file.
Thats it for now. Im depending on your feedback,
David
> Best regards,
>
> Thomas
>
> Thomas Schaeck
> IBM Pervasive Computing Division
> Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED]
> Address: IBM Deutschland Entwicklung GmbH,
> Schoenaicher Str. 220, 71032 Boeblingen, Germany
>
>
>
>
> --
> --------------------------------------------------------------
> Please read the FAQ! <http://java.apache.org/faq/>
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Archives and Other: <http://marc.theaimsgroup.com/?l=jetspeed>
> Problems?: [EMAIL PROTECTED]
>
>
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://marc.theaimsgroup.com/?l=jetspeed>
Problems?: [EMAIL PROTECTED]
