> -----Original Message----- > From: Todd Kuebler [mailto:[EMAIL PROTECTED] > Sent: Friday, October 24, 2003 3:10 PM > To: Jetspeed Developers List > Subject: RE: Jetspeed2 - User .vs. Integrator .vs. Core API/jars > > > That's a relatively simplistic answer, not really I was driving at. > People > are going to need to work on the portal end of things too (which I > indicated by including integrators btw). The JSR 168 API is really only > about the portlet itself as you pointed out, The details like layout and > such are left to the portal vendor, and if you are saying you only support > users using the JSR 168 API no-one will want to use your portal.
We are current working on a asynchronous rendering mechanism for portlet rendering. I would like to handle layouts using a mechanism similar WPS, were you basically just drop fragments into a theme and skin directories. > For > that sort of simplistic use you might as well use the container that comes > with pluto to run your portlet in. > > What if I need to do things at the session level, Please explain this further. >what about the security > interface, isn't that user modifiable We are looking at pluggable security using a combination of XMLACL and JAAS. David Le Strat has also been working on security and profiling proposals. > what about interportlet > communication This is a good question. The inter-portlet communications would need to be transparent to the end portlet application so as not to make the portlet non-portable. We have yet to address this functionality. Or we could say screw it, make it easy on ourselves and use proprietary hooks within portlet applications to allow them to cross communicate. Or both. > which is explicitly out of the spec? How about administrative functions, > role management, etc. There is also a Profiling proposal in project under the design-docs folder. Administration will most likely be a combination of JMX and some UIs. > These are all things the user will want access to > and are definately not part of the JSR 168 spec. The only value a > particular portal implementation adds is in these sorts of things, not > just > a strict JSR 168 API. The value a portlet brings is portablility > obviously, but a portal is way more than JSR 168! > > Come on, I was couching my question in simplistic terms to avoid confusion > and focus on details, not because I wanted a simplistic answer. Maybe I'm just a simple person. A lot of this stuff is up in the air until the core is more solid. Things like the asynchronous aggregator/rendering, have the spotlight now along with figuring out the best way to dispatch to portlet applications. > > > -tk *================================* | Scott T Weaver | | <[EMAIL PROTECTED]> | | Apache Jetspeed Portal Project | | Apache Pluto Portlet Container | *================================*
