I thought he had said something about that at the Jasig Unconference. And yes, *please* do share! :)
- Jen On May 20, 2010, at 10:20 AM, Carroll, Timothy Dale wrote: > We have a portlet deployer portlet that we are using for development > purposes. How about I have Andy submit that for incubation? > > TC > > > On May 20, 2010, at 8:12 AM, Jennifer Bourey wrote: > >> Hi Tim, >> >> I really appreciate the thoughtful feedback. It's really helpful to have >> people discuss strategy and desired features on list, and I hope we see more >> discussion in the future :) A couple comments below: >> >>> 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). >> >> Sounds like a pretty reasonable use case. Maybe at some point you could >> help create a list of features that are missing from the existing >> import/export portlet that you'd like to see? From what you've described, >> it sounds like a first step might be enabling the portlet to consume and >> export multiple files at a time. Perhaps we could consider having it >> consume and produce zipped directories of files similar to what's in >> uPortal's data directory? >> >> I have to admit I've been wanting to figure out how to use the Fluid >> uploader component for that portlet for a while, since it has a very nice >> interface for uploading multiple files. I'd also love to see a portlet >> deployment portlet, even if it were really only useful for single-machine >> development instances. >> >> >>> 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. >> >> Yes, it would be fantastic to have some stats tools. I think Eric actually >> has already done a little local work on some analysis tools. For the >> statistics, I think the most important first step would be to get the stats >> aggregation tool in the sandbox to work with non-Oracle databases. Once >> that's done, we could turn on the stats service by default and start >> collaborating on some tools. If you or anyone with some database expertise >> is willing to help out, that would really help get the project moving. >> >> Thanks again, >> >> - Jen >> >> >> -- >> 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 >> > > > -- > 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 > -- 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
