At 16:32 2000-11-20, you wrote:
> > -----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.
Have a look at the new docs/proposals/portletAPI directory in CVS, there
are already some documents in there...
ingo.
> > > 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]
--
--------------------------------------------------------------
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]
