[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