[11:47:43 CST(-0600)] <Arvids1> could it be that mobile view renders all portlets?
[11:47:56 CST(-0600)] <EricDalquist> by default yes it does
[11:48:09 CST(-0600)] <EricDalquist> I believe there is an option to disable mobile rendering on a per-portlet basis
[11:48:14 CST(-0600)] <Arvids1> emm... how can i avoid such behaviour?
[11:50:05 CST(-0600)] <Arvids1> ah.. now i get it
[11:54:12 CST(-0600)] <Arvids1> my question was a bit misleading - first mobile view (where only icons are showed) gives me an impression that content of each and every portlet in user layout gets rendered (but is not visible on the screen)
[11:54:23 CST(-0600)] <EricDalquist> nope
[11:54:41 CST(-0600)] <EricDalquist> all the portlets are executed in minimized windowstate
[11:54:57 CST(-0600)] <EricDalquist> and if they are well behaved that should take all of 10ms
[11:55:08 CST(-0600)] <Arvids1> ok
[11:55:25 CST(-0600)] <EricDalquist> the reason they render at all is the mobile view has support for badge #s
[11:55:35 CST(-0600)] <EricDalquist> and a few portlets set response properties that the mobile view uses
[11:55:46 CST(-0600)] <EricDalquist> athena and I have talked about adding a new uP specific WindowState
[11:55:54 CST(-0600)] <EricDalquist> name it DASHBOARD or some such
[11:56:10 CST(-0600)] <EricDalquist> and then uP would only actually render portlets that declare support for said WindowState
[11:56:18 CST(-0600)] <EricDalquist> saving some time and cpu
[11:56:30 CST(-0600)] <Arvids1> sounds reasonable
[11:56:42 CST(-0600)] <EricDalquist> but that is more of a "that would be nice" than "we need to have" so it hasn't really had any time spent on it
[11:56:45 CST(-0600)] <EricDalquist> beyond those thoughts
[11:59:54 CST(-0600)] <EricDalquist> how's the performance testing going?
[12:01:27 CST(-0600)] <Arvids1> really nice
[12:01:40 CST(-0600)] <Arvids1> we´re setting everything up today
[12:01:53 CST(-0600)] <EricDalquist> great
[12:02:06 CST(-0600)] <EricDalquist> so that permissions check fix addressed most of it?
[12:02:07 CST(-0600)] <Arvids1> our main portal page could handle like 40 rq/sec without any big problems
[12:02:10 CST(-0600)] <Arvids1> yes
[12:02:11 CST(-0600)] <EricDalquist> nice
[12:20:20 CST(-0600)] <Arvids1> I´m not sure why, but that dashboard view tries to render all portlets in ´normal´ window state :-/
[12:20:54 CST(-0600)] <EricDalquist> hrm, I thought we had put something in place in 4.0.3 that specifically fixed that
[12:23:06 CST(-0600)] <EricDalquist> maybe that was put in after 4.0.3 ...
[12:23:27 CST(-0600)] <athena> might have been
[12:23:38 CST(-0600)] <athena> i know at least one of the fixes we needed for umobile was after the 4.0.3 release
[12:24:33 CST(-0600)] <Arvids1> I´ll try to dig through the latest changes
[12:24:52 CST(-0600)] <EricDalquist> I'm looking right now as well
[12:27:38 CST(-0600)] <EricDalquist> https://issues.jasig.org/browse/UP-3334
[12:27:43 CST(-0600)] <EricDalquist> looks like it's a 4.0.4 issue
[12:28:23 CST(-0600)] <Arvids1> i´ve applied this one
[12:28:26 CST(-0600)] <EricDalquist> https://issues.jasig.org/browse/UP-3327
[12:28:36 CST(-0600)] <EricDalquist> but 3327 appears to be in 4.0.3
[12:30:37 CST(-0600)] <EricDalquist> you might need a data import
[12:30:38 CST(-0600)] <EricDalquist> https://github.com/jasig/uPortal/commit/9e539d6830c2cc3cfee9cce3a936f14ccd904b86
[12:31:07 CST(-0600)] <EricDalquist> to add the defaultWindowState param to your mobile stylesheet descriptors
[12:32:18 CST(-0600)] <Arvids1> yes, I was lookin at that exact commit and realized that our entities were imported before that patch
[12:34:05 CST(-0600)] <drewwills> morning EricDalquist... I can't remember if we previously discussed bundling the Notification portlet (in incubation) or not... I think we may have
[12:34:16 CST(-0600)] <EricDalquist> I can't either
[12:34:29 CST(-0600)] <drewwills> anthony cut a release of it last week
[12:34:39 CST(-0600)] <drewwills> it seems like now could be a good time
[12:34:58 CST(-0600)] <drewwills> it has a nice demo experience
[12:35:00 CST(-0600)] <EricDalquist> sounds good, are you going to setup the overlay and stuff?
[12:35:10 CST(-0600)] <drewwills> yes i can/ am happy to
[12:35:50 CST(-0600)] <athena> can we maybe talk about splitting out a jsr-286 branch for that, if it's going to be included in up4?
[12:36:07 CST(-0600)] <EricDalquist> I'm fine with bundling more stuff as long as it participates in filtering (db, logging, etc) correctly, and has a reasonable default dataset and portlet definition
[12:36:38 CST(-0600)] <athena> i think we also need to take import/export into consideration
[12:36:41 CST(-0600)] <drewwills> athena I don't believe any 286 work has been done on that one yet
[12:37:03 CST(-0600)] <EricDalquist> where does this thing store data?
[12:37:39 CST(-0600)] <drewwills> it has an interface-based API for pulling data... doesn't store it, unless you write one to store data
[12:37:56 CST(-0600)] <drewwills> for the demo experience it pulls demo data from the classpath
[12:38:05 CST(-0600)] <EricDalquist> ok, so what is the concern around import/export athena?
[12:38:24 CST(-0600)] <athena> none, since it doesn't store data 
[12:38:25 CST(-0600)] <drewwills> i thought that was just a general concern
[12:39:06 CST(-0600)] <EricDalquist> ah ok
[12:44:25 CST(-0600)] <Arvids1> regarding notifications - i´ve implemented another notificaton portlet (inspired by previously mentioned) but with some differences - concurrent notification retrieval, no extended description (hence no ajax)
[12:45:03 CST(-0600)] <Arvids1> ... and of course - changes in data classes
[12:46:18 CST(-0600)] <athena> would it make sense to contribute some of that back so we can all contribute to a shared project?
[12:46:32 CST(-0600)] <EricDalquist> +1 to that
[12:46:45 CST(-0600)] <Arvids1> requirements must be discussed, since i´ve taken a little bit another approach
[12:46:50 CST(-0600)] <athena> so i guess my biggest concern with including the notifications portlet out of the box right now is that it's a young project and the APIs might need to change
[12:47:06 CST(-0600)] <athena> and we may need to pull in changes brought up by things arvids or other schools notice
[12:47:23 CST(-0600)] <EricDalquist> ah
[12:47:35 CST(-0600)] <Arvids1> now it would be nice to have notification portlet on github
[12:47:35 CST(-0600)] <athena> i guess we just need to decide what level of API changes we're willing to have in a portlet between portal version numbers
[12:47:51 CST(-0600)] <athena> yes, moving to github would also help w/ the JSR-286 changes
[12:48:07 CST(-0600)] <athena> the umobile effort would like to use the notifications portlet to drive some new functionality
[12:48:19 CST(-0600)] <EricDalquist> one thing we should talk about with moving projects to github is how incubation on github will work
[12:48:32 CST(-0600)] <athena> particuarly add an event-based API so that other portlets could potentially publish notifications, then pull them all down in one JSON feed
[12:48:46 CST(-0600)] <EricDalquist> yeah
[12:49:02 CST(-0600)] <athena> do we have concerns about incubation on github?
[12:49:13 CST(-0600)] <EricDalquist> well just project designations