Thanks for the insight Tim.The one big blocking issue with moving the framework portlets out of the uPortal webapp is delegation. If enough administrative functions were pulled out we could in theory move all administrative portlets out into a single bundle but they could not be split up from that bundle. All of the admin portlets are using WebFlow for a number of reasons but the biggest is the simplicity which delegation to other flows can be done. This is a huge feature for the ability to re-use logic and UIs between portlet applications. Unfortunately even with JSR-286 support there is no way to do that sort of work between portlet applications.
Something Jen and I will be putting together shortly is a design document for the REST APIs that we will be focusing on in the near term. That could also provide a location for people to collaborate on additional APIs they would like to see in the future. As always with this type of work the hardest part is the API design since once these are published they are a public API which we have to maintain going forward.
-Eric On 5/20/10 12:16 AM, Carroll, Timothy Dale wrote:
Thanks Jen. Unfortunately, I don't get to follow all the postings in the list a closely as I'd like, so it is good to get a summary of the activity and direction. Your points are well made, and I think your proposed approach is a good one. One point that I'd like to clarify is the distinction you make between external administrative portlets and bundled administrative portlets. IMO we should strive for all portlets to be external, but have a uPortal bundle that includes a suite of administrative portlets and perhaps suites of other portlets. In other words, I think we should work toward eliminating the concept of "framework" portlets. I understand the current need and place for them, but I've also been skeptical about their use outside of a transitional strategy. As far as use cases, your current vision covers most of them; however, here are a couple items that i don't think are covered but may have some merit: 1. I like the idea of exposing all the import/export features (even entity types for example) through a web service API. We do frequent environment reloads for test environments, and I think an API like that would enable some cool batch automations in that area. And, it may also provide (more readily) support for distributing the load of those batch processes to other machines. I still see Cernunnos being leveraged here but in a way that allows remoting as a separate distinct application. Some other uses of this in a prod environment might be extracting that data and munging/analyzing things in an application used for... troubleshooting, reporting, provisioning, or deprovisioning (again running on a separate machine to distribute any load). 2. The other area I can think of right away would be the actions related to the stats database. Some analysis tools would likely bubble up quickly as result of some API exposure there. All that being said. I don't think this has any impact on the priorities that you and Eric have outlined. Those are well founded. I would just hope that a broader vision might attract and encourage the contributions of other eager developers out there. TC On May 19, 2010, at 9:58 AM, Jennifer Bourey wrote:I'm hopeful that we'll be able to start actively developing the target REST services once the Spring 3 update is complete. Some of the refactoring I've done in the last month was specifically designed to make our permissions systems more re-usable by portlets living outside of the uPortal webapp. I think it'll be great to start exposing clear APIs through REST, and I don't have any objection to people potentially developing new administrative tools for uPortal. That said, I'd like to remind everyone that we're currently in the middle of doing significant refactoring to essentially all of the portal's administrative portlets. If there are changes or additions you'd like to see in uPortal's administrative toolset, this would actually be a great time to discuss those use cases on-list. While it might be possible to develop external portlets to perform administrative tasks, I'd also like to ensure that uPortal ships with friendly, useful administrative portlets that meet the needs of most adopting institutions. It may turn out that we find reasons to develop some tools as external portlets, but I'd like to first try to fold any missing features into the default toolset. We've been actively soliciting input about our new administrative tools, so if you have suggestions, please let us know. If you're interested in plans for the next version of the permissions portlet, some documentation and wireframes is available at http://www.ja-sig.org/wiki/display/UPC/Permissions+Manager+Portlet. Beyond that, I'd suggest that we prioritize REST services for things that are genuinely useful and are good targets for modification outside of the portal. For example, it might not actually be a good idea to allow external portlets to do things like delete entity types. That seems unlikely to have a clear use case and would be particularly likely to cause errors in the portal. It might be helpful to talk about some real use cases in the community and discuss what operations would be useful in portlet development. From my perspective, the highest value REST service for portlet development will likely center around groups, users, and permissions. - Jen On May 19, 2010, at 10:41 AM, Eric Dalquist wrote:Thanks for the page. It would be great to move this discussion to the uportal-dev list. For a current efforts status update. JenB is working on rewriting the AJAX UI features for 3.3, part of that effort is creating a set of REST based APIs using Spring 3's REST annotation support. The end goal for these APIs is to have them published as a standard way for code external to uPortal to perform administrative tasks. The initial focus for functionality will be the calls needed for portlet manager, groups manager, permissions manager, end user layout management and fragment layout management. I'm not sure exactly what her status is on these but I know she is stuck a bit on the service implementation since we can't update trunk to Spring 3 until I get the Pluto 2 branched merged back in, which will hopefully be happening some time next week. Another note I'll make on the page, links to the Pluto Driver API docs aren't all that usefull, the driver is Pluto's demo portal and we won't actually be using any code from that or the driver-impl package in 3.3 final. -Eric On 05/19/2010 09:15 AM, Gary Weaver wrote:http://www.ja-sig.org/wiki/display/UPC/Proposal+for+Standardizing+Portal+Services I know that we don't have resources for it, but I thought I may as well follow through with a proposal based on Tim's interest in it. Not much, and may not help, but at least it is documented. --- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user-- Jen Bourey Software Developer Unicon, Inc. -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
smime.p7s
Description: S/MIME Cryptographic Signature
