David,
thanks for your excellent description. See my remarks below ...
> 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.
Do you mean "applied to each request" or just "applied to each
request for a page that needs to be generated using a PSML file" ?
> 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.
Good, CC/PP is the relevant standard for this.
> 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....
As I understand, building a target resource URL would be what the
default ProfilerService does, while other profilers would e.g. build
SQL queries to access databeas, or whatever is suitable for them.
Each profiler implementation will return a Profile object that can
later be passed to the code that generates the pages... Very good.
> 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.
We were discussing this topic recently. I think what you are saying here
is not overkill; it is the direction that should be taken. We should
consider the following concept:
Each portlet ref should have a unique id. The settings for a portlet ref
should be accessible via a persistence service. (We are currently working
on a persistence service and plan to make a proposal for that soon), that
allows to set/get per-user, per-portlet, per-page properties.
The first implementation of such a persistence service should still store
the portlet properties in the PSML files. Other implementations may follow
that use a database to store/retrieve the portlet properties for a given
portlet ref on a given page of a given user.
>
> 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
In the future, there may be multi-mime-type capable controllers,
controls and portlets and it may happen that the same psml is usable
for several mime types. In that scenario, something like this would
be possible:
A user has a 3G UMTS Phone, a PC and a Palm Pilot. He may have
customized the following pages and mapped them to devices like this:
(PC, Mozilla, default )->default_html.psml(News,Weather...)
(PC, Mozilla, financial)->page1.psml(Stocks,CompanyNews)
(PDA, WML browser,default )->default_wml.psml(News,Weather)
(PDA, WML browser,financial)->page2.psml(Stocks)
(3G Phone,WML browser,default )->default_wml.psml(News,Weather)
(3G Phone,WML browser,fun )->page3.psml(Cinema,Theatre)
This led us in the direction of having a set of pages per user that
are not mapped to device/mime types through their position in a
directory tree but rather through a file or database entries.
> 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.
Great!
> 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.
Why ?
To me, the roles concept seems orthogonal to mapping of users to
PSMLs. I'll now write up some ideas that are coming to my mind,
maybe they are useful:
How about providing class(es) for the following mappings
User -> Profile
User -> Role (default)
Role -> Profile
(User, Role) -> boolean
There might be intrefaces like these:
public interface Profiler {
public Profile getProfile(User user);
public Profile getProfile(Role role);
}
public interface Principal {
public Role getDefaultRole();
public boolean isInRole(Role role);
}
Assume user has the type principal - a portal could do the following
things alternatively (pseudocode):
display(profiler.getProfile(user));
or
display(profiler.getProfile(user.getDefaultRole());
or
if (user.isInRole(role)) {
display(profiler.getProfile(role));
} else {
// not allowed
}
I think Java Security uses concepts like roles and principals already,
maybe that may be relevant here ...
> -------
> 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.
Sounds very reasonable.
> ------------
> 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?
Disclaimer: What I say now does not refer to the current JetSpeed
implementation, this is rather a statement about how things should be
(see the Portlet API outline that we recently checked in).
It is possible to instantiate a portlet only once per PortletConfig.
If it has access to a PortletContext, PortletRequest, PortletResponse,
PortletSession and a PersistenceService that gives access to per-user,
per-portlet, per-page data, it is possible to react on each request in
a way that depends on the request, current state (transient state in
the PortletSession, persistent state in the persistent store) and user
identity.
> 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 )
I'm not sure what you mean here, can you explain this in more detail ?
My assumption would be that a portlet ref exists from the point in time
where it is added to a PSML by a customizer until it is removed by a
customizer. Whenever the page that contains it is displayed, the
references portlet is displayed using the parameters specified in the
portlet ref (or in the future perhaps using parameters references from
within the portlet ref).
> 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.
This should be done via a PersistenceService that should be an extension of
the Portlet API (see the Portlet API outline that we recently checked in).
> TODO: better describe portlet scoping.
>
> What else...
> -- The ProfilerService is a Turbine service and is specified in the
turbine
> properties file.
But we would have a ProfilerService interface and a ServiceFactory in
JetSpeed
so that the JetSpeed implementation would not depend on Turbine, I assume.
Is that what you intend ?
>
> 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]
