> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of [EMAIL PROTECTED]
> Sent: Saturday, November 18, 2000 9:48 AM
> To: JetSpeed
> Subject: RE: Profiler
>
>
>
>
>
> 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" ?
>
Good question.
Tell me, what other kinds of requests are handled by Jetspeed?
It appears to me that not all requests always lead to generating a full psml
page.
For instance, full screen applications such as the portlet viewer screen:
http://localhost:8080/content/servlet/jetspeed/screen/portlets.PortletViewer
Screen/portlet/Applications
or any other Turbine module. Please refresh my memory. How do we expect to
intercept requests and send them to the profiler service for all Turbine
screens used in Jetspeed. I could see how we would do this by subclassing
the Turbine servlet. From what ive seen on the msg threads, this will no
longer be possible.
In the codebase today, the Profiler is only invoked on requests to
org\apache\jetspeed\turbine\screens\Home.java
> > 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.
>
This sounds great.
I believe a persistence service is the right way to go.
Can I have a look at the interfaces?
> >
> > 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.
>
OK. That sounds reasonable.
> > 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
> }
>
This is very good. I will rework it
> 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 really need more info on the new Portlet API before I can go into more
detail on this.
> > 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]
>
>
--
--------------------------------------------------------------
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]
