David,
Looks like a missed something on the mailing list...
Some of the services listed below, shouldn't be services IMHO. Others I can
see, although I am not clear at this stage what methods they should provide.
Each service should have a well-definied, agreed-upon interface as part of
the Portlet API. All we can provide at this stage is a (set of) service
factory method(s). Can put one in, but as long as no services are defined it
seems wrong to do so. For example, should the factory just return a
reference to a singleton, or should new service objects be created each
time? Or do we need both? At any rate, registration should be off - that's
definitely implementation detail of the portlet container.
If anyone wants to step in and define an abstract service add-on for the
Portlet API, you are more than welcome to do so! As it wrote before, adding
things is easy, just removing is bad.
Yes, David, the Portlet API is Portlet API, not a Portal API.
Where did you see PortletData? I should be DynamicData...
I didn't understand you window events example... There is (intrinsic)
support for windows events in the new Portlet API. But maybe it was an
example for something else...
Cheers,
Thomas B.
----- Original Message -----
From: "David Sean Taylor" <[EMAIL PROTECTED]>
To: "JetSpeed" <[EMAIL PROTECTED]>
Sent: Wednesday, February 07, 2001 21:21
Subject: RE: Secure Portlets
Thomas,
I was under the impression that a Portlet(Portal) API would define
interfaces for all aspects of a portal container: services, the layout
system, etc.
>From reading your comments, the scope of the Portlet API is now a little
more clear.
The quote below is from the PortletAPIRequirements doc, perhaps I am
misunderstanding it:
<quote>
The Portlet API should allow for definition of service interfaces and for
registration of services implementing particular service interfaces, e.g.
User info (for getting user info like name, address, age...)
Persistence (for storing per-user, per-portlet settings)
Location (for obtaining the user's location)
Personalization (for storing/getting personalization info)
Data (access to databases, schema-to-object mappings)
Content (access to syndicated content)
Cache (access to URLs via caches)
...
Rationale: This allows for a stable API core that can be extended by
services as required. Portals implementing the Portlet API can provide
implementations for a subset of the services defined in the Portlet API.
</quote>
> Generally, I think the services approach is futile in the Portal API,
> because the whole purpose of a well-defined API is that a portlet
> can run on
> any portlet container implementing that API.
So we still need to define standard service interfaces, right?
Its just not part of the 'Portlet' API. I am thinking that the Portlet API
shields the portlet developer from these services, which are used internally
in the portlet container.
Take for example, Window Events.
I assume they are some how connected to Window Managers (from Raphael's
proposal), but the portlet doesn't use the WindowManager interfaces, it will
instead handle window events. Are the components described in Raphael's
proposal 'implementation only', or will they be a part of some 'standard'
interface-api?
Or, PortletData and DynamicData. (whats the difference?)
Perhaps they are somehow persisting attributes using the PersistenceService.
> I still take comments and feedback. Is there no more interest in a new API
> or is everyone busy doing other things?
No, there's a lot of interest.
I know how that feels when you put a proposal out, and no one responses -
and i hate that.
My apologies.
I will send more specific questions about the interfaces soon...
- david
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Thomas F. Boehme
> Sent: Wednesday, February 07, 2001 4:21 AM
> To: JetSpeed
> Subject: Re: Secure Portlets
>
>
> Maybe I am missing something, but a portlet should not be concerned with
> things like a profiler service. Instead the profiler service determines
> which and how a portlet is called. Again, I may be missing something, but
> that's how I see it and that's why there isn't anything like that shining
> through in the API.
>
> A general service API has been left out of the most recent API
> because there
> needs to be more information on the type of services we are talking about.
> Generally, I think the services approach is futile in the Portal API,
> because the whole purpose of a well-defined API is that a portlet
> can run on
> any portlet container implementing that API. Services not known at
> compile-time seem to defeat that purpose.
>
> WRT, User and UserProfile -- that's a "bug" - it should be "User" only. An
> update will be posted soon (there are a few other things that
> were reported
> to me).
>
> I still take comments and feedback. Is there no more interest in a new API
> or is everyone busy doing other things?
>
> Thomas B.
>
>
> ----- Original Message -----
> From: "David Sean Taylor" <[EMAIL PROTECTED]>
> To: "'JetSpeed'" <[EMAIL PROTECTED]>
> Sent: Tuesday, February 06, 2001 18:56
> Subject: RE: Secure Portlets
>
>
> Chris,
>
> Yes, the profiler does support groups, but the security isn't implemented.
> So you could take the JetspeedProfilerService and extend with security.
>
> I will be doing just that, but first Im more concerned with how profiling
> services will work with the portlet api.
> I've seen that the portlet API has a User and ProfileUser object, but its
> not apparent if a 'profiling service' is even defined as a
> standard service.
>
> Thomas, could you explain how profiling services plug into the
> Portlet API?
> Sorry but its not apparent to me...
>
> Thanks,
>
> David
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Kimpton,C (Chris)
> > Sent: Tuesday, February 06, 2001 3:07 AM
> > To: 'JetSpeed'
> > Subject: Secure Portlets
> >
> >
> > Hi,
> >
> > We want to make our portlet secure - so that only users in
> > specific groups
> > can access it.
> >
> > From the Jetspeed features, it seems like the profiler
> > service should allow
> > this - but I've not tracked down any more info on this yet.
> >
> > Any quick answers available on how this should be done - is a
> > jetspeed.jcfg
> > setting? Or a method needed in our Portlet?
> >
> > TIA,
> > Chris
> >
> > ==============================================================
> > ==================================
> > This electronic message (email) and any attachments to it are
> > subject to copyright and are sent for the personal attention
> > of the addressee. Although you may be the named recipient, it
> > may become apparent that this email and its contents are not
> > intended for you and an addressing error has been made. This
> > email may include information that is legally privileged and
> > exempt from disclosure. If you have received this email in
> > error, please advise us immediately and delete this email and
> > any attachments from your computer system.Rabobank
> > International is the trading name of Coöperatieve Centrale
> > Raiffeisen-Boerenleenbank B.A. which is incorporated in the
> > Netherlands. Registered with the Registrar of Companies for
> > England & Wales No. BR002630 and regulated by the SFA for the
> > conduct of investment business in the UK.
> >
> > The presence of this footnote also confirms that this email
> > has been automatically checked by Rabobank International for
> > the presence of computer viruses prior to it being sent,
> > however, no guarantee is given or implied that this email is
> > virus free upon delivery.
> >
> >
> >
> >
> > --
> > --------------------------------------------------------------
> > To subscribe: [EMAIL PROTECTED]
> > To unsubscribe: [EMAIL PROTECTED]
> > Search: <http://www.mail-archive.com/[email protected]/>
> > List Help?: [EMAIL PROTECTED]
> >
> >
>
>
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Search: <http://www.mail-archive.com/[email protected]/>
> List Help?: [EMAIL PROTECTED]
>
>
>
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Search: <http://www.mail-archive.com/[email protected]/>
> List Help?: [EMAIL PROTECTED]
>
>
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
