...
[15:29:28 CDT(-0500)] <EricDalquist> but it never went anywhere
[15:3233:36 39 CDT(-0500)] <drewwills> i like this approach for all parties leveraging the same code, but i fear (and i may be missing pieces of the picture) i could get the java-based, portal context API integration thing working faster
[15:33:02 CDT(-0500)] <drewwills> and with less messy config steps in the client webapp
[15:33:08 CDT(-0500)] <drewwills> fewer*
[15:33:21 CDT(-0500)] <drewwills> ah but wait
[15:33:21 if I had this I could hit ANY rest api... not just ones I had made interfaces for
[15:33:40 CDT(-0500)] <EricDalquist> so designing a whole new API, implementation and way to provide it as a portal context attribute?
[15:33:42 CDT(-0500)] <athena> it sort of seems like most of the planning is already there? you'd just need to implement the steps eric already laid out
[15:33:46 CDT(-0500)] <EricDalquist> right
[15:34:00 CDT(-0500)] <athena> yes, you could hit any of the existing rest services
[15:34:08 CDT(-0500)] <athena> plus quickly attach to new ones you created
[15:34:14 CDT(-0500)] <drewwills> yeah I was picturing a "whole new API" of 1 interface, maybe 2 methods 
[15:34:14 CDT(-0500)] <EricDalquist> this already exists: https://github.com/Jasig/portlet-utils
[15:34:15 CDT(-0500)] <athena> so if you needed a new service you could jsut add it to uportal and go
[15:34:33 CDT(-0500)] <EricDalquist> yes but it needs to be a well thought out API
[15:34:36 CDT(-0500)] <athena> so we just need a small library that's a submodule of portlet-utils
[15:34:38 CDT(-0500)] <athena> yes, it does
[15:38:06 CDT(-0500)] <drewwills> this is about getting all oars in the same boat, rowing the same way
[15:38:47 CDT(-0500)] <EricDalquist> right
[15:39:00 CDT(-0500)] <EricDalquist> the portal context api integration?so I thinkt he least effort is the rest api proxy code