> Have a look at the new docs/proposals/portletAPI directory in CVS, there
> are already some documents in there...
Thanks Ingo, I already had this but I didnt know it.
Typical developer, I never look under the docs. I always go straight to src
:)
David
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of ingo schuster
> Sent: Monday, November 20, 2000 7:57 AM
> To: JetSpeed
> Subject: RE: Profiler
>
>
> 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.Po
> rtletViewer
> >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]
>
>
--
--------------------------------------------------------------
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]
