Portals and portletsdotLRN includes a replacement portals package that should be used to replace the current OpenACS portals package. The improvements are so obvious and significant that I won't bother listing them here.
I would like to see us remove the existing portals package entirely and to include the one written for dotLRN. I personally see no need to keep the name "new-portals" as the name, we could just call it "portals".
It looks to me as though there's still work to be done on the UI. In dotLRN portals are added to pages automatically by the applet mechanism so there's not so much need for a complete UI for portals themselves. This can be addressed later by the OpenACS crew.
So, then ... why have separate portlets packages for standard OpenACS packages?
These are simple presentation templates that could easily be segregated by name ("foo-portlet", etc) or by placement into package-key/portlets or package-key/www/portlets.
They're deeply intertwined with their base package, and changes to the base package need to be reflected in the associated portlets. Keeping portlet packages separate from base packages doubles the list of packages one has to deal with when interacting with the APM.
And I feel strongly that we want future package implementors to provide usable portlets for new packages. Describing a proper application package as being composed of datamodel, tcl library, page templates and portlets would naturally lead to people thinking of portlets as being necessary components of new packages. Splitting them into separate packages would encourage implementors to think of them as being optional or something to be left for the future.
Also, eventually I'd like to see us move to a portal-based admin UI with admin portlets provided for each package, possibly in 4.6, certainly in 4.7, with the acs-subsite package responsible for building a control panel page which includes admin portlets for packages mounted underneath it. The control panel concept first appeared in ACES, is now included in the standard ACS 3.5 release maintained by Sussedorf and Roy, and has been implemented in dotLRN as well. It's a good concept.
Why not incorporate it into OpenACS 4?
This implies that application packages would be required to include, at minimum, admin portlets, which strengthens the case for not separating portlet and base packages.
Is there a good technical reason for keeping portlets unbundled from their base packages?