[10:51:38 CDT(-0500)] <EricDalquist> that's a fun bug in calendar portlet 1.0 
[10:52:30 CDT(-0500)] <athena> i guess? i'm actually surprised that that causes such misbehavior
[10:52:47 CDT(-0500)] <EricDalquist> so in uP4 I added entity versioning to all our JPA objects
[10:52:53 CDT(-0500)] <EricDalquist> as a form of optomistic locking
[10:53:03 CDT(-0500)] <EricDalquist> every time an object is updated its version number increments
[10:53:07 CDT(-0500)] <athena> ah
[10:53:08 CDT(-0500)] <EricDalquist> and the updates all include the version number
[10:53:18 CDT(-0500)] <athena> so the misbehavior is up4-specfic?
[10:53:22 CDT(-0500)] <EricDalquist> prevents concurrent updates from stepping on each other
[10:53:23 CDT(-0500)] <EricDalquist> yeah
[10:53:33 CDT(-0500)] <EricDalquist> essentially concurrently updating portlet preferences has always been bad
[10:53:33 CDT(-0500)] <athena> well, good to know
[10:53:46 CDT(-0500)] <EricDalquist> in uP3 it would fail silently, last update always won
[10:53:53 CDT(-0500)] <EricDalquist> in uP4 it fails loudly
[10:54:06 CDT(-0500)] <EricDalquist> if you really have a concurrent preference update use case you need to sync on the session or some such
[10:54:36 CDT(-0500)] <athena> i know we actually talked at this at some point
[10:54:50 CDT(-0500)] <athena> and for that portlet we knew it was fine if the last update won
[10:55:02 CDT(-0500)] <athena> don't think there was discussion around it actually creating performance problems
[10:55:02 CDT(-0500)] <EricDalquist> huh
[10:55:05 CDT(-0500)] <EricDalquist> yeah
[10:55:34 CDT(-0500)] <EricDalquist> well and I'm going to look into adding more logic in the preferences service
[10:55:41 CDT(-0500)] <EricDalquist> so that if you don't actually change anything
[10:55:45 CDT(-0500)] <EricDalquist> and call store nothing happens
[10:55:45 CDT(-0500)] <athena> ok, great
[10:55:56 CDT(-0500)] <EricDalquist> since that code looks like it will be setting the same value every time
[10:56:08 CDT(-0500)] <athena> well, the days is
[10:56:25 CDT(-0500)] <athena> i worry that other portlets may be doing similar things, and not always setting the same value
[10:56:33 CDT(-0500)] <EricDalquist> yeah
[10:56:37 CDT(-0500)] <athena> like the news reader portlet definitely used to set the feedId as a preference
[10:56:48 CDT(-0500)] <EricDalquist> on every ajax request?
[10:56:50 CDT(-0500)] <athena> so that when you came back to the portlet it would remember the last feed you looked at
[10:56:57 CDT(-0500)] <athena> yes
[10:56:59 CDT(-0500)] <EricDalquist> so it all depends
[10:57:12 CDT(-0500)] <EricDalquist> it seems like the cal portlet does lots of concurrent ajax requests per user
[10:57:23 CDT(-0500)] <EricDalquist> in that case modifying prefs in each can be bad
[10:57:46 CDT(-0500)] <athena> i don't think it should be doing concurrent ajax requests
[10:58:00 CDT(-0500)] <EricDalquist> I'm not sure how else bruce could be getting that error
[10:58:01 CDT(-0500)] <athena> i'm not sure why we'd be seeing those at all, actually
[10:58:13 CDT(-0500)] <athena> the portlet makes one when loaded
[10:58:24 CDT(-0500)] <athena> then makes a request any time the user changes the date, etc.
[10:58:32 CDT(-0500)] <EricDalquist> hrm
[10:58:44 CDT(-0500)] <EricDalquist> so I just realized there is locking in the prefs service too
[10:58:58 CDT(-0500)] <athena> you know . . . i think they have a single-feed version of the calendar and may be displaying a bunch of calendar portlets on a page
[10:59:00 CDT(-0500)] <EricDalquist> in prefs service .store the code gets a Lock scoped to the portlet entity
[10:59:02 CDT(-0500)] <athena> don't know if that might be a factor
[11:00:21 CDT(-0500)] <EricDalquist> oh ... huh
[11:00:29 CDT(-0500)] <EricDalquist> my lock and tx are not scoped correctly
[11:02:05 CDT(-0500)] <EricDalquist> the lock happens inside the tx
[11:02:09 CDT(-0500)] <EricDalquist> but it shuld happen outside
[11:02:42 CDT(-0500)] <athena> ooh
[11:02:59 CDT(-0500)] <EricDalquist> since hibernate doesn't actually flush anything to the DB until the TX completes
[11:03:05 CDT(-0500)] <EricDalquist> that means the lock is released and then the commit happens
[11:03:08 CDT(-0500)] <EricDalquist> not the other way around
[11:51:40 CDT(-0500)] <peterjhart> What is everyone's favorite way to edit the user agent for the different browsers?
[11:52:24 CDT(-0500)] <athena> with firefox i have a plugin
[11:52:28 CDT(-0500)] <athena> in safari it's built-in
[11:53:14 CDT(-0500)] <EricDalquist> chome is built in too
[11:53:36 CDT(-0500)] <athena> is it on os x now?
[11:53:53 CDT(-0500)] <EricDalquist> yeah
[11:54:01 CDT(-0500)] <EricDalquist> it is hidden in the dev tool
[11:55:16 CDT(-0500)] <peterjhart> Just saw the blog post about Chrome. It looks like they added that in December.
[11:55:29 CDT(-0500)] <peterjhart> I haven't had to edit my user agent for a long while
[11:55:53 CDT(-0500)] <peterjhart> took me a very long time to figure out that is how you see the mobile skin
[11:56:04 CDT(-0500)] <peterjhart> so... workin on the documentation...
[12:06:13 CDT(-0500)] <peterjhart> I was thinking there would be a setting in the code to show the mobile version when in development
[12:06:39 CDT(-0500)] <athena> hmm, interesting
[12:07:06 CDT(-0500)] <athena> in the past we just told people to use safari because the old mobile theme didn't work well on non-webkit browsers anyway
[12:07:32 CDT(-0500)] <athena> new one is better though
[12:08:37 CDT(-0500)] <athena> if you want to change the default, you could go into userContext.xml and add a new rule to match .* to mobileDefault
[12:09:36 CDT(-0500)] <peterjhart> oh
[12:10:13 CDT(-0500)] <athena> we just match profiles on regexes
[12:10:27 CDT(-0500)] <peterjhart> the mobile theme in uP4 assumes the viewport is only 320x480
[12:11:22 CDT(-0500)] <athena> which probably doesn't make sense anymore
[12:11:30 CDT(-0500)] <athena> what should we be doing?
[12:11:49 CDT(-0500)] <peterjhart> my first answer is "responsive design"
[12:12:00 CDT(-0500)] <peterjhart> but that might not be the whole solution
[12:12:24 CDT(-0500)] <peterjhart> because it seems like there are many backend changes when the user is on a mobile device
[12:12:29 CDT(-0500)] <peterjhart> e.g. some portlets don't show
[12:12:58 CDT(-0500)] <peterjhart> responsive design loads different CSS based on screen size
[12:13:45 CDT(-0500)] <peterjhart> its a feature of CSS3.
[12:14:28 CDT(-0500)] <peterjhart> So, when EricDalquist refers to "4.1", is that the same thing as master?
[12:14:46 CDT(-0500)] <EricDalquist> right now there is no 4.1
[12:14:57 CDT(-0500)] <EricDalquist> "real soon now" I'll be create a 4.0 branch
[12:15:01 CDT(-0500)] <peterjhart> I thought you said you put the SASS/Maven stuff into 4.1
[12:15:04 CDT(-0500)] <EricDalquist> and updating master to 4.1.0-SNPASHOT
[12:15:07 CDT(-0500)] <EricDalquist> I will be
[12:15:12 CDT(-0500)] <EricDalquist> it is all on a working branch right now
[12:15:16 CDT(-0500)] <peterjhart> ok
[12:15:19 CDT(-0500)] <EricDalquist> until I make sure I have it sorted out
[12:15:34 CDT(-0500)] <EricDalquist> I think I have things straight so I'm going to try and do that this weekend
[12:15:55 CDT(-0500)] <peterjhart> the SASS in muniversality looks to be in disarray. I don't know if I can get to it today
[12:16:39 CDT(-0500)] <EricDalquist> not a problem
[12:16:51 CDT(-0500)] <EricDalquist> I just won't touch the .css files for the muniv stuff
[12:17:07 CDT(-0500)] <peterjhart> k