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
