Here are some things that I've been thinking about since the conference, inspired by presentations and discussions I had there:
The idea I've been toying around with is to take Pluto and wrap it with a custom JSF component, which would be similar to what Jason did with his JSP tag, but I wouldn't need a portal engine, just the portlet container. JSF components are stateful so this component should be able to handle anything that Pluto would normally need a full portal engine to take care of. Couple this with Facelets, and you would have a (nearly) pure XHTML way to create a website, sprinkling in portlets where you see fit.
- There was a lot of talk about WSRP. I was unable to find out why anyone would want to use WSRP as it seems to be a solution in search of a problem, but that is just my personal opinion. The consensus of the group seemed to be that WSRP is a good thing to have and that there currently is no decent community (i.e, open source) implementation of WSRP, since the WSRP4J project is still in incubation and it has several bugs besides. Tim Rault-Smith of Sun was there and said that they will be open sourcing the Sun Portal product, including its WSRP stack, so hopefully the community will soon have a decent implementation.
- There were several talks about security, which is a difficult problem in Grid environments. Kurt Mueller talked about GAMA 2, which will be available in the next month or so. I talked about my work with the PURSe portlets. Jipu Jiang talked about using Shibboleth with GridSphere. I had a discussion with Tim Rault-Smith about how we are doing authentication and authorization in the LEAD Portal. Our authorization scheme in the LEAD Portal is based on SAML, using these things called capability tokens. What I dislike about them is that they are time-limited just like Globus proxy certificates, and so we run into the same set of issues we experience with proxy certificates; in other words, they are always expiring at the worst moment. What would be nice is either a more lightweight authorization scheme or perhaps if it were possible to grant a capability to a user limited not in time but in "space", that is, limited to only a particular instance of a service, or limited to a single invocation of the service (which of course implies that the service is somehow stateful).
- Chuck was there, talking about all things Sakai, and it was good to see him again. He wants to make Sakai a JSR 168 portlet container, and I think that's a great idea. I would love to use Sakai this way, I've never been keen on running Sakai as a separate portal and linking into the LEAD portal via iframes.