/
uPortal IRC Logs-2010-09-21

uPortal IRC Logs-2010-09-21

[08:38:55 CDT(-0500)] <awills> how easy or difficult would it be to deploy the ResourceServingWebapp to a different context name and have uPortal & portlets work with it there?
[10:55:21 CDT(-0500)] <athena> hey eric - you said something about us not being ready to use etags on the main portal page?
[10:55:47 CDT(-0500)] <EricDalquist> for the .uP page, other resources on the page can use them{color}
[10:56:01 CDT(-0500)] <athena> what's the blocker w/ the .up page?

[10:56:16 CDT(-0500)] <EricDalquist> we need to be able to calculate an absolute state key
[10:56:23 CDT(-0500)] <EricDalquist> we're closer with the new rendering pipeline
[10:56:34 CDT(-0500)] <EricDalquist> but the portlet caching code doesn't exist yet
[10:56:55 CDT(-0500)] <EricDalquist> that is needed and then a way to figure out how to generate an etag value from what is a big Serializable object
[10:57:02 CDT(-0500)] <athena> oh!
[10:57:12 CDT(-0500)] <athena> so there's this new ShallowEtagHeaderFilter in spring 3
[10:57:30 CDT(-0500)] <EricDalquist> I had some ideas last night about how to do it
[10:57:41 CDT(-0500)] <athena> i was going to try that out for the ajax controllers
[10:57:45 CDT(-0500)] <athena> maybe we could just use that?
[10:57:48 CDT(-0500)] <EricDalquist> do browsers scope etags to a specific user?
[10:57:54 CDT(-0500)] <EricDalquist> how does it work?
[10:57:57 CDT(-0500)] <athena> http://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/web/filter/ShallowEtagHeaderFilter.html
[10:57:59 CDT(-0500)] <EricDalquist> doesn't it just save the network IO?
[10:58:06 CDT(-0500)] <athena> i think it's just based on the content
[10:58:14 CDT(-0500)] <EricDalquist> yeah so you still do all the server-side work
[10:58:36 CDT(-0500)] <athena> which server-side work?
[10:58:54 CDT(-0500)] <EricDalquist> so when you do "get /ajax/channelList"
[10:59:00 CDT(-0500)] <EricDalquist> and the browser presents the etag
[10:59:06 CDT(-0500)] <EricDalquist> the portal still has to build the channelList
[10:59:08 CDT(-0500)] <EricDalquist> and send it out
[10:59:12 CDT(-0500)] <EricDalquist> the fitler just intercepts that
[10:59:26 CDT(-0500)] <EricDalquist> and sends a not-modified if the content hasn't changed
[10:59:36 CDT(-0500)] <EricDalquist> so all it saves on is the data transfer
[10:59:40 CDT(-0500)] <athena> right
[10:59:46 CDT(-0500)] <athena> but that's still worth doing
[10:59:50 CDT(-0500)] <EricDalquist> right
[10:59:59 CDT(-0500)] <athena> i think that's all etags ever do, isn't it?
[11:00:00 CDT(-0500)] <EricDalquist> so we could do that to start for everything
[11:00:06 CDT(-0500)] <athena> yeah
[11:00:18 CDT(-0500)] <athena> we'll still have to appropriately cache content and such
[11:00:25 CDT(-0500)] <EricDalquist> well the controller could be smarter and handle them natively
[11:00:36 CDT(-0500)] <EricDalquist> like I was thinking about how to do it for the rendering pipeline
[11:00:53 CDT(-0500)] <athena> interesting
[11:01:00 CDT(-0500)] <EricDalquist> the new pipeline API caching is based on all components implementing a getCacheKey(req, res) API
[11:01:20 CDT(-0500)] <athena> so you're suggesting maybe it would just send back the same etag based on knowing that nothing has changed, rather than calculating an etag from the content?
[11:01:26 CDT(-0500)] <EricDalquist> so at the top level you could generate a random etag value and store a Map<ETag, CacheKey> in the user's session
[11:01:42 CDT(-0500)] <athena> yeah, that'd be pretty neat
[11:02:13 CDT(-0500)] <EricDalquist> then in the rendering controller you do: 1. lookup CacheKey for Etag, 2. call getCacheKey(req, res) on pipeline, 3. if the CacheKey from the session and the CacheKey from the pipeline match return NOT_MOD
[11:02:29 CDT(-0500)] <EricDalquist> so you completely skip doing any rendering work on the portal side
[11:02:37 CDT(-0500)] <EricDalquist> that same thing can be done for all of our ajax controllers
[11:02:41 CDT(-0500)] <athena> yeah
[11:03:06 CDT(-0500)] <athena> probably worthwhile (smile)
[11:03:10 CDT(-0500)] <EricDalquist> yeah
[11:03:28 CDT(-0500)] <athena> and maybe actually less data to cache in some cases
[11:03:40 CDT(-0500)] <athena> since you would just need to cache an etag, rather than all the bits that build the content
[11:03:49 CDT(-0500)] <EricDalquist> so do browsers scope etags at all for https?
[11:04:04 CDT(-0500)] <athena> i'm not sure
[11:04:10 CDT(-0500)] <EricDalquist> like what if user A logs into the portal and we send back Etag XY
[11:04:17 CDT(-0500)] <EricDalquist> then they log out and user B logs into the portal
[11:04:27 CDT(-0500)] <EricDalquist> will the browser send Etag XY for their request?
[11:05:01 CDT(-0500)] <athena> that's a good question
[11:05:39 CDT(-0500)] <athena> i guess that's a good reason to think about doing some of this stuff ourselves
[11:05:44 CDT(-0500)] <EricDalquist> right
[11:05:56 CDT(-0500)] <EricDalquist> we need to be careful that it is impossible to fish for other user's content
[11:05:59 CDT(-0500)] <athena> yeah
[11:06:15 CDT(-0500)] <athena> definitely a good point
[11:06:29 CDT(-0500)] <EricDalquist> use either secure hashing (SHA256) or random tokens at least 256bits in length
[11:07:01 CDT(-0500)] <athena> use random tokens for ?
[11:07:08 CDT(-0500)] <EricDalquist> for the etag value
[11:07:10 CDT(-0500)] <athena> ah
[11:07:11 CDT(-0500)] <athena> yews
[11:07:16 CDT(-0500)] <EricDalquist> like in my rendering pipeline example
[11:07:34 CDT(-0500)] <EricDalquist> we would just generate a random token for the etag value and associate it with the CacheKey in the user's session
[11:07:49 CDT(-0500)] <EricDalquist> since we need that CacheKey to verify if we need to re-render or not
[11:08:23 CDT(-0500)] <EricDalquist> in theory if all portlets are cached and the user hits reload the rendering pipeline should be able to skip anything other than key generation
[11:08:46 CDT(-0500)] <EricDalquist> PS: I hate dealing with transient portlets in the guest layout right now
[11:08:53 CDT(-0500)] <athena> right - that all makes a lot of sense
[11:08:59 CDT(-0500)] <EricDalquist> the guest user in general is such a pain at times
[11:09:00 CDT(-0500)] <athena> the guest layout is a pain in general
[11:09:02 CDT(-0500)] <athena> lol
[11:09:03 CDT(-0500)] <athena> yes.
[11:09:15 CDT(-0500)] <EricDalquist> I'm hoping to have time to fix that in trunk
[11:09:27 CDT(-0500)] <EricDalquist> with the better caching I'm hoping we can get rid of all the special handling for "guest"
[11:09:35 CDT(-0500)] <athena> and it'll really speed up the gallery to have the portlet only download the channel list when necessary
[11:09:47 CDT(-0500)] <athena> that'd be really nice
[11:09:49 CDT(-0500)] <athena> so hmm.
[11:10:24 CDT(-0500)] <athena> i wonder if there's a way that i can try out something like that for the channel list
[11:11:47 CDT(-0500)] <EricDalquist> yeah it's a little tricky, you need your generated etag to be aware of any potential change in the backend data stores
[11:12:14 CDT(-0500)] <athena> yeah
[11:12:38 CDT(-0500)] <athena> guess it's harder since we're just relying on annotated methods for caching there - don't think we're doing any explicit caching
[11:12:59 CDT(-0500)] <EricDalquist> yeah
[11:13:07 CDT(-0500)] <EricDalquist> and the data is sensitive to changes in multiple systems
[11:13:16 CDT(-0500)] <athena> yes
[11:13:20 CDT(-0500)] <athena> and needs to be per-user
[11:13:51 CDT(-0500)] <EricDalquist> yup
[11:13:59 CDT(-0500)] <EricDalquist> I think the fitler is the best we'll do for now
[11:14:17 CDT(-0500)] <EricDalquist> I don't think we have much hope for a custom etag until the related API is completely re-written
[11:14:30 CDT(-0500)] <athena> which API?
[11:14:44 CDT(-0500)] <athena> guess i'm not sure we can use a filter, given the username issues
[11:15:06 CDT(-0500)] <EricDalquist> hrm
[11:15:12 CDT(-0500)] <EricDalquist> I guess it depends on how they generate the tag
[11:15:20 CDT(-0500)] <EricDalquist> if it is a secure has based on the content
[11:15:23 CDT(-0500)] <EricDalquist> then that's safe
[11:15:38 CDT(-0500)] <EricDalquist> since it is esentially doing string matching on the output
[11:15:56 CDT(-0500)] <athena> let me find the javadoc for it
[11:16:08 CDT(-0500)] <athena> http://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/web/filter/ShallowEtagHeaderFilter.html
[11:16:09 CDT(-0500)] <athena> ok
[11:16:14 CDT(-0500)] <athena> looks like it is just content-based
[11:16:19 CDT(-0500)] <EricDalquist> as for the API, any of them, the backing logic needs to be such that a cache key for the data can be known without generating the data
[11:16:21 CDT(-0500)] <athena> Filter that generates an ETag value based on the content on the response. This ETag is compared to the If-None-Match header of the request. If these headers are equal, the response content is not sent, but rather a 304 "Not Modified" status instead.
[11:17:01 CDT(-0500)] <EricDalquist> looks like it does MD5 hashing by default
[11:17:36 CDT(-0500)] <EricDalquist> ARG
[11:17:39 CDT(-0500)] <athena> lol
[11:17:41 CDT(-0500)] <EricDalquist> I HATE Windows
[11:18:05 CDT(-0500)] <EricDalquist> so XSLTC can't load relative XSL imports on windows for some reason
[11:18:11 CDT(-0500)] <EricDalquist> which is why Gary is having problems
[11:18:27 CDT(-0500)] <athena> you think we'd need to switch it to a stronger algorithm w/ jasypt?
[11:18:33 CDT(-0500)] <athena> oh (sad)
[11:18:47 CDT(-0500)] * athena wound like to ban windows
[11:18:48 CDT(-0500)] <athena> and IE!
[11:19:06 CDT(-0500)] <EricDalquist> not sure, I don't know enough about crypto (tongue)
[11:19:24 CDT(-0500)] <EricDalquist> you could probably just use the built in MessageDigest and do some version of SHA
[11:19:55 CDT(-0500)] <athena> probably - i think it's just a lot easier to do SHA w/ jasypt, from what i remember
[11:20:30 CDT(-0500)] <athena> i guess in theory there could be sensitive data somewhere in the portlet registry
[11:20:55 CDT(-0500)] <EricDalquist> yeah
[11:21:07 CDT(-0500)] <EricDalquist> one thing I was thinking is that we really should trim the data the channelList returns
[11:21:21 CDT(-0500)] <EricDalquist> there is no reason the subscribe UI can access more than name, title & fname
[11:21:38 CDT(-0500)] <EricDalquist> things like parameters shouldn't be sent
[11:23:21 CDT(-0500)] <athena> actually we're using the channel parameters to set the portlet icons
[11:23:43 CDT(-0500)] <EricDalquist> hrm
[11:23:51 CDT(-0500)] <EricDalquist> yeah
[11:23:53 CDT(-0500)] <athena> though we could potentially trim the model down to just send that parameter through
[11:24:09 CDT(-0500)] <athena> don't know if we have any other use cases - i stripped out all the support for users overriding channel params
[11:24:25 CDT(-0500)] <EricDalquist> I guess in trunk this isn't an issue
[11:24:45 CDT(-0500)] <EricDalquist> since parameters are going to be re-tooled for XSL related info only
[11:24:59 CDT(-0500)] <EricDalquist> just could be a problem for someone using CWebProxy in 3.2
[11:25:04 CDT(-0500)] <EricDalquist> or any other channel
[11:25:14 CDT(-0500)] <EricDalquist> and having things in the parameters they don't want users to see
[11:28:19 CDT(-0500)] <athena> yes
[11:28:23 CDT(-0500)] <athena> hm
[11:28:36 CDT(-0500)] <athena> so what security algorithm would you like to use for etags?
[11:29:08 CDT(-0500)] <EricDalquist> I don't know ... I don't feel qualified to answer that :/
[11:29:16 CDT(-0500)] <athena> lol
[11:29:17 CDT(-0500)] <EricDalquist> maybe we can do some searching for etag security issues
[11:29:30 CDT(-0500)] <athena> to be honest, i'm not sure how strong encryption we can use without it becoming annoying
[11:29:43 CDT(-0500)] <athena> some algorithms require you to set up your JVM for them
[11:30:21 CDT(-0500)] <EricDalquist> right
[11:30:30 CDT(-0500)] <EricDalquist> I know all the SHA stuff is in the JDK by default
[11:31:32 CDT(-0500)] <athena> yeah
[11:31:45 CDT(-0500)] <athena> so we could probably do that if i could remember the string that represents that
[11:31:48 CDT(-0500)] <EricDalquist> some basic searching looks like md5 is quite popular
[11:32:16 CDT(-0500)] <EricDalquist> so lets just go with the default spring filter for now
[11:32:20 CDT(-0500)] <athena> ok
[11:32:29 CDT(-0500)] <athena> that is indeed easier (smile)
[11:33:06 CDT(-0500)] <athena> i think i can probably port this filter class to uportal 3.2
[11:33:19 CDT(-0500)] <athena> (for backporting the gallery)
[11:33:51 CDT(-0500)] <EricDalquist> grr
[11:34:04 CDT(-0500)] <EricDalquist> so in a dlm fragment the header/footer content is ignored during merging right?
[11:34:33 CDT(-0500)] <athena> i actually have no idea
[11:34:40 CDT(-0500)] <athena> i don't know much about how that's all merged together
[11:37:18 CDT(-0500)] <EricDalquist> trying to get our search portlet working on the guest layout
[11:37:29 CDT(-0500)] <EricDalquist> and the portlet has to be part of the guest user's layout to display
[12:09:10 CDT(-0500)] <EricDalquist> arg this XSL resource loading stuff is a pain
[12:58:03 CDT(-0500)] <athena> gaaaaah
[12:58:18 CDT(-0500)] <athena> this filter is insisting that the response doesn't have a status code
[12:58:34 CDT(-0500)] <EricDalquist> uhg
[12:58:50 CDT(-0500)] <athena> yeah, dunno what's up with that
[12:58:58 CDT(-0500)] <athena> need to walk through it w/ a debugger i guess
[13:27:45 CDT(-0500)] <athena> EricDalquist: you have any objection to upping the spring version in trunk?
[13:28:19 CDT(-0500)] <EricDalquist> nope
[13:28:28 CDT(-0500)] <athena> looks like that'll fix the etag issue
[13:28:30 CDT(-0500)] <EricDalquist> though I thought it broke the webflows at one point whenI tried
[13:28:35 CDT(-0500)] <athena> oh
[13:28:37 CDT(-0500)] <athena> that's bad.
[13:30:25 CDT(-0500)] <EricDalquist> worth a try though
[13:30:30 CDT(-0500)] <EricDalquist> easy enough to change it
[13:31:53 CDT(-0500)] <athena> yeah
[13:31:55 CDT(-0500)] <athena> i'll try it out
[13:32:06 CDT(-0500)] <athena> and i guess we need to look at switching the SpEL anyway?
[13:32:31 CDT(-0500)] <EricDalquist> yeah
[13:34:06 CDT(-0500)] <athena> is the syntax totally different?
[13:34:15 CDT(-0500)] <EricDalquist> I don't think it is that diffeent
[13:34:25 CDT(-0500)] <athena> ok
[13:34:25 CDT(-0500)] <EricDalquist> I would guess that a bunch of stuff still works even
[13:34:29 CDT(-0500)] <athena> awesome
[13:42:18 CDT(-0500)] <athena> hm.
[13:42:25 CDT(-0500)] <EricDalquist> yay got the windows XSL loading issue fixed
[13:42:49 CDT(-0500)] <EricDalquist> just realized doing it though that right now every time the theme XSL renders messages.xml is completely re-loaded (sad)
[13:43:23 CDT(-0500)] <athena> so weblfow mostly works
[13:43:34 CDT(-0500)] <athena> finding random things that are broken but they're probably unrelated
[13:43:46 CDT(-0500)] <athena> oh
[13:43:52 CDT(-0500)] <athena> so we're not going to have messages.xml anymore anyway
[13:44:09 CDT(-0500)] <athena> so if we just transition the messages that are left in it we could get rid of it (smile)
[13:44:27 CDT(-0500)] <athena> i did get the new i18n stuff working for XSLT
[13:44:56 CDT(-0500)] <EricDalquist> yup
[13:44:59 CDT(-0500)] <EricDalquist> I saw that
[13:45:03 CDT(-0500)] <EricDalquist> and that will be good
[13:45:10 CDT(-0500)] <EricDalquist> help save some cycles
[13:45:17 CDT(-0500)] <athena> ooh i think this etag crap is finally working
[13:45:42 CDT(-0500)] <EricDalquist> yay
[13:48:01 CDT(-0500)] <athena> hmmm
[13:48:07 CDT(-0500)] <athena> channel list still isn't working quite right
[13:48:25 CDT(-0500)] <athena> though tab list seems to be
[13:48:26 CDT(-0500)] <athena> weird.
[13:49:19 CDT(-0500)] <athena> the channel list seems to be generating different etags each time
[13:49:39 CDT(-0500)] <EricDalquist> weird
[13:49:48 CDT(-0500)] <athena> not sure if the content really is changing somehow
[13:49:50 CDT(-0500)] <EricDalquist> ordering perhaps?
[13:49:55 CDT(-0500)] <athena> yeah, that's what i was thinking
[13:50:03 CDT(-0500)] <athena> i think that the categories are unordered
[13:50:14 CDT(-0500)] <athena> betting this is all just a map
[13:50:40 CDT(-0500)] <EricDalquist> LinkedHashMap is your friend
[13:50:43 CDT(-0500)] <athena> yep
[13:50:48 CDT(-0500)] <athena> Map<String,Object>
[13:50:56 CDT(-0500)] <athena> i'll switch it, since we actually care about the order now
[13:51:11 CDT(-0500)] <athena> don't think it really mattered in the past
[13:52:08 CDT(-0500)] <athena> combined w/ your performance change, this might actually make a pretty significant difference in user experience
[13:52:24 CDT(-0500)] <EricDalquist> nice
[13:52:41 CDT(-0500)] <athena> so did i ask you whether you'd fixed the issue w/ importing portlet preferences containing HTML?
[13:52:51 CDT(-0500)] <EricDalquist> yes, and no
[13:52:55 CDT(-0500)] <athena> i remember that you looked at it and thought you said stuff in cdata was working or something
[13:53:01 CDT(-0500)] <EricDalquist> I have it fixed locally
[13:53:05 CDT(-0500)] <athena> ah ok
[13:53:08 CDT(-0500)] <EricDalquist> hven't had time to get the patch back in svn
[13:53:17 CDT(-0500)] <athena> gotcha
[13:53:34 CDT(-0500)] <athena> i'm trying to fix up unicon's demo before educause and was thinking about trying to do some content portlet demos
[13:53:52 CDT(-0500)] <EricDalquist> I can see about getting it back in this afternoon
[13:53:57 CDT(-0500)] <athena> oh - no rush
[13:54:17 CDT(-0500)] <athena> i mean we can always demo it w/o initialized content too
[13:54:24 CDT(-0500)] <athena> was just curious
[13:54:37 CDT(-0500)] <athena> guess maybe we could include it in the next 3.2.x release if the bug is fixed though (smile)
[13:54:47 CDT(-0500)] <athena> and i can get the web proxy content migrated in trunk
[13:57:46 CDT(-0500)] <athena> shoot.
[13:57:56 CDT(-0500)] <athena> channel list controller returns all this stuff in random order as well
[13:58:56 CDT(-0500)] <athena> i guess we'll need to sort the list before building the registry
[13:59:38 CDT(-0500)] <EricDalquist> TreeMap?
[13:59:43 CDT(-0500)] <EricDalquist> I have to run to a meeting
[13:59:48 CDT(-0500)] <EricDalquist> I'll be back in an hour
[14:01:16 CDT(-0500)] <athena> cya
[16:10:35 CDT(-0500)] <athena> EricDalquist: switched over to spring 3.0.4 and SpEL-based expression parsing and things are looking pretty good!
[16:10:42 CDT(-0500)] <EricDalquist> yay!
[16:10:42 CDT(-0500)] <athena> person lookup works again
[16:10:46 CDT(-0500)] <EricDalquist> (big grin)
[16:10:47 CDT(-0500)] <EricDalquist> awesome
[16:10:55 CDT(-0500)] <athena> i'm sure there are some things int he flows that are going to need to be fixed up, but it seems like it works on the whole
[16:11:02 CDT(-0500)] <athena> so we can just tweak those when we find them
[16:11:09 CDT(-0500)] <athena> like we need to do .keys() instead of .keys
[16:11:11 CDT(-0500)] <athena> simple stuff like that
[16:11:25 CDT(-0500)] <athena> and my new account store seems to be finding users and user attributes (smile)
[16:11:32 CDT(-0500)] <EricDalquist> great
[16:11:57 CDT(-0500)] <athena> so do i need to actually implement the deprecated methods?
[16:12:05 CDT(-0500)] <athena> or will those go away by the time we cut a release
[16:12:05 CDT(-0500)] <EricDalquist> no
[16:12:52 CDT(-0500)] <athena> no to which one, lol
[16:13:15 CDT(-0500)] <EricDalquist> no to having to implement them
[16:13:18 CDT(-0500)] <athena> awesome
[16:13:22 CDT(-0500)] <athena> i like that ansewr
[16:13:28 CDT(-0500)] <athena> so w/ the aggregation stuff
[16:13:28 CDT(-0500)] <athena> l
[16:13:28 CDT(-0500)] <athena> o
[16:13:50 CDT(-0500)] <athena> looks like the theme pulls in the .aggr versions no matter what?
[16:14:01 CDT(-0500)] <EricDalquist> it shouldn;t ...
[16:14:05 CDT(-0500)] <athena> or for now do i need to clear the theme cache or log in again or something?
[16:14:09 CDT(-0500)] <EricDalquist> hrm
[16:14:18 CDT(-0500)] <athena> i can see if those make a difference
[16:14:22 CDT(-0500)] <EricDalquist> oh yeah
[16:14:30 CDT(-0500)] <EricDalquist> the aggregation state isn't part of the cache key
[16:14:31 CDT(-0500)] <EricDalquist> (tongue)
[16:14:37 CDT(-0500)] <EricDalquist> oops
[16:14:51 CDT(-0500)] <EricDalquist> so clearing the theme cache would fix it
[16:15:24 CDT(-0500)] <athena> oh ok
[16:15:26 CDT(-0500)] <athena> no problem
[16:15:32 CDT(-0500)] <athena> i can tell mpolizzotti how to do that as wel
[16:15:53 CDT(-0500)] <EricDalquist> yeah I can look at that tonight
[16:16:00 CDT(-0500)] <athena> at least we can get around it (smile)
[16:16:46 CDT(-0500)] <EricDalquist> yeah
[16:18:48 CDT(-0500)] <EricDalquist> oh I've been meaning to ask
[16:19:03 CDT(-0500)] <EricDalquist> what would you think about sticking all of our remoting/ajax controllers in a single package?
[16:19:12 CDT(-0500)] <EricDalquist> right now they get picked up twice by the spring component scan
[16:19:50 CDT(-0500)] <athena> yes, i think that would be a terrific idea
[16:20:02 CDT(-0500)] <athena> i objected to having this stuff in dlm.remoting from day 1
[16:20:10 CDT(-0500)] <EricDalquist> then we can exclude that package from the main app context scan
[16:20:22 CDT(-0500)] <EricDalquist> and only have the DispatcherServlet context load it up
[16:20:28 CDT(-0500)] <EricDalquist> also what are we currently using for a base URI?
[16:20:36 CDT(-0500)] <EricDalquist> /ajax/ ?
[16:20:42 CDT(-0500)] <athena> which is also silly
[16:20:52 CDT(-0500)] <athena> gah
[16:20:55 CDT(-0500)] <athena> we're using /mvc
[16:20:59 CDT(-0500)] <EricDalquist> uhg
[16:21:00 CDT(-0500)] <EricDalquist> yeah
[16:21:03 CDT(-0500)] <athena> stupid (smile)
[16:21:05 CDT(-0500)] <EricDalquist> any idea?
[16:21:16 CDT(-0500)] <athena> using /ajax sounds great to me
[16:21:19 CDT(-0500)] <EricDalquist> ok
[16:21:28 CDT(-0500)] <EricDalquist> do you have much in-progress work locally?
[16:21:31 CDT(-0500)] <athena> eventually we should think about what we're going to do for REST
[16:21:36 CDT(-0500)] <EricDalquist> right
[16:21:37 CDT(-0500)] <athena> yeah
[16:21:48 CDT(-0500)] <athena> i should at least check in the channel list stuff i did in the last hour before we move it
[16:21:48 CDT(-0500)] <EricDalquist> so maybe /ajax/ for now
[16:21:54 CDT(-0500)] <athena> yeah i think that's good
[16:22:03 CDT(-0500)] <athena> and we can eventually start thinking about a /rest/ path or whatever
[16:22:04 CDT(-0500)] <EricDalquist> and as we have a better idea for REST services add in /rest/
[16:22:06 CDT(-0500)] <EricDalquist> yeah
[16:22:15 CDT(-0500)] <athena> things like the entity search might be a logical first target for that
[16:22:26 CDT(-0500)] <mpolizzotti> Sorry, this is from a few posting ago...but I know how to clear the theme cache with the uPortal Cache Manager. Eric, thanks for checking in those updates. I really appreciate it.
[16:22:41 CDT(-0500)] <EricDalquist> no problem.
[16:22:49 CDT(-0500)] <EricDalquist> we'll see what we can do to really get it fixed up
[16:23:12 CDT(-0500)] <EricDalquist> I don't want this stuff to make xsl/css/js work more difficult
[16:23:18 CDT(-0500)] <EricDalquist> if anything it needs to be easier
[16:23:25 CDT(-0500)] <athena> agreed!
[16:23:36 CDT(-0500)] <athena> we want to make it really easy for UE people to contribute
[16:23:39 CDT(-0500)] <EricDalquist> yeah
[16:23:41 CDT(-0500)] <athena> makes such a big difference
[16:23:51 CDT(-0500)] <EricDalquist> in theory the XSL auto-refreshes when changed
[16:23:51 CDT(-0500)] <athena> i really like the new up theme
[16:23:53 CDT(-0500)] <athena> pretty
[16:23:59 CDT(-0500)] <EricDalquist> but right now the problem is the xsl:imports
[16:24:09 CDT(-0500)] <EricDalquist> the loader code only sees the reference to the main XSL file
[16:24:23 CDT(-0500)] <athena> sweet, i think all this etag stuff is finally working
[16:24:40 CDT(-0500)] <EricDalquist> great
[16:25:14 CDT(-0500)] <mpolizzotti> I take credit for the new theme, that's Gary Thompson, but I am helping on the new gallery and tab management tools.
[16:25:19 CDT(-0500)] <EricDalquist> I also need to writeup docs on how to convert a DLM processor
[16:25:35 CDT(-0500)] <athena> nice typo there matt (wink)
[16:26:01 CDT(-0500)] <mpolizzotti> oh...sorry (wink)
[16:26:03 CDT(-0500)] <athena> lol
[16:26:15 CDT(-0500)] <mpolizzotti> I mean, I can't take credit.
[16:26:19 CDT(-0500)] <athena> i like the gallery too, for what it's worth
[16:26:40 CDT(-0500)] <mpolizzotti> The UI is really looking nice.
[16:27:41 CDT(-0500)] <athena> yeah
[16:27:49 CDT(-0500)] <athena> i'm really looking forward to the tabs stuff
[16:28:23 CDT(-0500)] <mpolizzotti> I should have the tab stuff checked in either later today or by tomorrow.
[16:28:41 CDT(-0500)] <athena> awesome
[16:28:55 CDT(-0500)] <athena> hoping to check some of my changes in soon
[16:29:16 CDT(-0500)] <athena> but first need to figure out why suddenly a bunch of the channels aren't showing up in the add stuff menu (sad)
[17:09:29 CDT(-0500)] <athena> wooo, i feel like i finally accomplished something today