uPortal IRC Logs-2009-02-11

Owned by Apereo Infrastructure
Last updated: Feb 11, 2009Version comment
13 min read

[00:23:20 EST(-0500)] * athena7 (n=athena7@ip68-230-77-209.ph.ph.cox.net) has joined ##uportal
[04:59:11 EST(-0500)] * higmad (n=chatzill@pcit-8752.HIG.SE) has joined ##uportal
[08:23:53 EST(-0500)] * michelled (n=michelle@CPE001310472ade-CM0011aefd3ca8.cpe.net.cable.rogers.com) has joined ##uportal
[08:25:17 EST(-0500)] * bszabo_ (n=bszabo@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[08:32:05 EST(-0500)] * colinclark (n=colin@bas2-toronto09-1176131452.dsl.bell.ca) has joined ##uportal
[09:38:59 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[09:51:39 EST(-0500)] * lennard1 (n=sparhk@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[10:04:08 EST(-0500)] * michelled (n=michelle@CPE001310472ade-CM0011aefd3ca8.cpe.net.cable.rogers.com) has left ##uportal
[10:13:56 EST(-0500)] * awills (n=awills@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[10:24:46 EST(-0500)] <dstn> awills and EricDalquist, thanks for the groovy comment, it fixed that issue
[10:24:57 EST(-0500)] <EricDalquist> (smile)
[10:25:04 EST(-0500)] <EricDalquist> thanks for working on those 2.x export scripts
[10:25:10 EST(-0500)] <EricDalquist> it will be wonderful to get those updated
[10:25:39 EST(-0500)] <EricDalquist> one thing you want to watch for if you're using the latest scripts from trunk is that you're not exporting 3-1 entity files
[10:25:44 EST(-0500)] <EricDalquist> or they won't import into 3-0
[10:26:57 EST(-0500)] <EricDalquist> awills: if you can get that PD update done this morning I can probably include it in 3.1.0-M2
[10:30:28 EST(-0500)] <dstn> EricDalquist, I gotta leave for a bit, can you explain more on the 3-1 entity files when I get back?
[10:30:34 EST(-0500)] <EricDalquist> yup
[10:32:59 EST(-0500)] <awills> you're most welcome dstn; EricDalquist I can get right on it in 5 min
[10:33:23 EST(-0500)] * holdorph (n=holdorph@uni1.unicon.net) has joined ##uportal
[10:35:57 EST(-0500)] * athena7 (n=athena7@12.164.139.7) has joined ##uportal
[10:58:33 EST(-0500)] <athena7> I don't know if you've cut releases yet, EricDalquist, but the fix for http://www.ja-sig.org/issues/browse/UP-2019 could probably be applied to 3.0.3 as well
[10:58:56 EST(-0500)] <EricDalquist> I haven't
[10:59:01 EST(-0500)] <EricDalquist> you want to see if you can apply it?
[11:00:46 EST(-0500)] * colinclark (n=colin@142.150.154.101) has joined ##uportal
[11:04:02 EST(-0500)] <athena7> sure
[11:04:11 EST(-0500)] <athena7> i think that should be quick enough i can take care of it
[11:04:42 EST(-0500)] <athena7> oh.
[11:04:54 EST(-0500)] <athena7> it looks like i did take care of it using svn-merge
[11:05:00 EST(-0500)] <athena7> let me test it
[11:06:19 EST(-0500)] <athena7> hey the fix version on this one is set
[11:06:19 EST(-0500)] <athena7> argh.
[11:06:37 EST(-0500)] <athena7> my search function isn't being very friendly today i guess
[11:06:45 EST(-0500)] <athena7> well, guess i already took care of that, cool (smile)
[11:06:58 EST(-0500)] <EricDalquist> (smile)
[11:07:23 EST(-0500)] <athena7> i think we were hoping to get the up-2047 work into 3.1 - as a beta portlet, if nothing else
[11:07:52 EST(-0500)] <athena7> most of it's done, but i'm not sure we can finish the group/channel select piece until the end of the month
[11:08:06 EST(-0500)] <EricDalquist> ok ... sounds like we need to talk a bit more about that
[11:08:24 EST(-0500)] <EricDalquist> and what the developers are comfortable with including as far as something with limited testing
[11:09:16 EST(-0500)] <athena7> yeah
[11:09:45 EST(-0500)] <athena7> my previous hope, even with more testing, was to add the portlet, but not link to it as an official administrative portlet
[11:10:04 EST(-0500)] <athena7> have it available for those that are interested in trying it out, but not make it a default resource until the next release
[11:10:17 EST(-0500)] <athena7> sort of like we did w/ the ajax preferences
[11:19:29 EST(-0500)] * michelled (n=team@142.150.154.193) has joined ##uportal
[11:26:54 EST(-0500)] <awills> PERSONDIR-49 is in, eric
[11:30:48 EST(-0500)] <EricDalquist> great
[13:53:13 EST(-0500)] * athena7 (n=athena7@12.164.139.7) has joined ##uportal
[14:18:01 EST(-0500)] <EricDalquist> athena7: one thing I'm taking care of in trunk is explicitly listing the version of the yuicompressor-maven-plugin in the pom
[14:18:19 EST(-0500)] <EricDalquist> we want all dependencies, plugins included, to have versions explicitly listed so builds are reproducable
[14:29:34 EST(-0500)] <EricDalquist> heh, just realized you already did that (smile)
[14:49:26 EST(-0500)] * colinclark (n=colin@142.150.154.101) has joined ##uportal
[14:52:57 EST(-0500)] * SixEcho (n=SixEcho@99-147-133-115.lightspeed.dllstx.sbcglobal.net) has joined ##uportal
[14:57:33 EST(-0500)] <SixEcho> I'm looking to use SSO to simply authenticate a user... but my one constraints is that my Website (Consumer) cannot see the Authentication server (Provider) – it's on a private network.... (the Provider can see my Consumer, but not versa) Is there any way that CAS can operate with these constraints? Or that there can be some pre-configured trust between Consumer/Provider so they don't need to communicate directly?
[14:58:47 EST(-0500)] <SixEcho> i.e. can it all be done /w front-channel exchange (browser redirects) and a trusted secret between CAS/Consumer – or CAS -> Consumer communication. (i.e. not Consumer -> CAS)
[15:04:39 EST(-0500)] <athena7> EricDalquist: i did, but maybe we want the version number in the main pom instead?
[15:05:37 EST(-0500)] <EricDalquist> athena7: I think it is fine where it is, there isn't as nice of a dependencyManagement structure for plugins as there is for regular dependencies
[15:06:01 EST(-0500)] <athena7> ok (smile)
[15:06:26 EST(-0500)] <EricDalquist> SixEcho: you probably want to check on the CAS email lists
[15:06:36 EST(-0500)] <EricDalquist> I'm not sure how many CAS gurus we have here
[15:07:12 EST(-0500)] <SixEcho> EricDalquist: ok, was wondering - this was the only irc channel i could find on the cas website – was worth a try (tongue)
[15:07:23 EST(-0500)] <EricDalquist> no problem
[15:07:33 EST(-0500)] <EricDalquist> some times there are people here that can field CAS questions
[15:07:39 EST(-0500)] <EricDalquist> but I don't think any of them are around right now
[16:00:46 EST(-0500)] * athena7_ (n=athena7@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[16:11:31 EST(-0500)] * Tuomaz_ (n=fredrik@kaffe.umdc.umu.se) has joined ##uportal
[16:16:22 EST(-0500)] * awills1 (n=awills@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[16:42:41 EST(-0500)] * awills (n=awills@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[16:48:36 EST(-0500)] * athena7 (n=athena7@12.164.139.7) has joined ##uportal
[17:00:14 EST(-0500)] <EricDalquist> athena7: are you comfortable with where 3.0.3 is for me to do a release tonight?
[17:00:39 EST(-0500)] <athena7> yes, i think so
[17:00:45 EST(-0500)] <EricDalquist> great{color}
[17:00:52 EST(-0500)] <athena7> i don't think i know of any more tickets that are quickly fixable
[17:01:04 EST(-0500)] <athena7> and it seems like we've got a reasonable set of improvements
[17:01:13 EST(-0500)] <athena7> brb
[17:15:11 EST(-0500)] * athena7 cheers for releases
[17:16:16 EST(-0500)] * apetro (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[17:20:00 EST(-0500)] <athena7> EricDalquist: do you have any preferences on the URL styles for the javascript server? do we want to just link to the actual file and run it through a filter, or do we want to have a servlet that will return a file (or files) for some defined parameters or url path?
[17:20:27 EST(-0500)] <EricDalquist> well if we write it as a ServletFilter
[17:20:39 EST(-0500)] <EricDalquist> you can use URL patterns in web.xml to apply it to any JS URL style
[17:21:01 EST(-0500)] <EricDalquist> a fun trick with ServletFilters is they can be applied to static resources
[17:21:18 EST(-0500)] <EricDalquist> so if you map it to *.js it would apply to all requests ending in .js
[17:23:15 EST(-0500)] <athena7> yeah we'll probably end up wanting to serve up css resources as well
[17:23:25 EST(-0500)] <EricDalquist> yup
[17:23:39 EST(-0500)] <athena7> i don't know if you have thoughts on what sort of url style we'd like
[17:23:45 EST(-0500)] <EricDalquist> then we just need to document in the setup instructions a URL style
[17:24:18 EST(-0500)] <EricDalquist> perhaps an example like /js/framework/subname/1.2.3.a/filename.js
[17:24:45 EST(-0500)] <EricDalquist> so google uses: http://ajax.googleapis.com/ajax/libs/jquery/1.3.1/jquery.min.js
[17:24:57 EST(-0500)] <EricDalquist> library name and version in the URL
[17:25:07 EST(-0500)] <EricDalquist> along with any other unique information about the file
[17:25:35 EST(-0500)] <EricDalquist> could then also do /css/library/version/filename.css
[17:26:33 EST(-0500)] <EricDalquist> all we're really doing is just documenting some recommendations
[17:26:52 EST(-0500)] <EricDalquist> and pointing out how important well named URLs are with the filter due to the caching headers being set
[17:30:01 EST(-0500)] <athena7> yeah
[17:30:24 EST(-0500)] <athena7> i don't know if we want any ability to serve up a couple files at a time
[17:30:37 EST(-0500)] <athena7> i'm nto sure how much it matters
[17:30:56 EST(-0500)] <EricDalquist> I don't think so
[17:31:02 EST(-0500)] <athena7> some people have seemed pretty concerned in the past with the results of things like YSlow and their recommendations on minimizing http requests
[17:31:06 EST(-0500)] <EricDalquist> I think initially we should just go for the base feature set
[17:31:09 EST(-0500)] <EricDalquist> gzip and cache headers
[17:31:13 EST(-0500)] <EricDalquist> yeah
[17:31:20 EST(-0500)] <EricDalquist> we can look into that down the road
[17:31:24 EST(-0500)] <athena7> but i don't think we have much opportunity to do that anyway, because we need to keep them separate so they get cached
[17:31:25 EST(-0500)] <athena7> yeah
[17:31:39 EST(-0500)] <athena7> so i've got gzip and cache header functionality sitting on my machine right now
[17:31:50 EST(-0500)] <EricDalquist> the problem is we can't really ship things too optimized since each school is going to have its own set of includes
[17:31:51 EST(-0500)] <athena7> really simple cache-setting filter, and ehcache's gzip filter
[17:31:56 EST(-0500)] <EricDalquist> nice
[17:32:27 EST(-0500)] <athena7> so i guess we could add some sort of url-mapping servlet or something, but i'm not sure we even need that right now
[17:32:37 EST(-0500)] <EricDalquist> I don't think so either
[17:32:41 EST(-0500)] <athena7> ok
[17:32:47 EST(-0500)] <athena7> sounds like a start
[17:32:49 EST(-0500)] <EricDalquist> its probably better if people just put the files in well named directories
[17:32:52 EST(-0500)] <athena7> yeah
[17:32:57 EST(-0500)] <athena7> that sounds totally reasonable to me
[17:32:58 EST(-0500)] <EricDalquist> it will be easier to remember to change version numbers then (hopefully)
[17:33:09 EST(-0500)] <athena7> i can check in what i've got now, although we don't have real releases for a bunch of the files yet
[17:33:26 EST(-0500)] <EricDalquist> if we can make a very little maven project for that then we can just include the artifact into uPortal and the various portlets
[17:33:33 EST(-0500)] <EricDalquist> that's fine
[17:33:45 EST(-0500)] <EricDalquist> this would be in sandbox/?
[17:33:52 EST(-0500)] <athena7> yeah
[17:33:58 EST(-0500)] <athena7> so what i'd built was the actual webapp
[17:34:15 EST(-0500)] <athena7> i'm not sure if it really makes sense to create a .jar
[17:34:37 EST(-0500)] <athena7> since we're just using ehcache's gzipping technology
[17:34:40 EST(-0500)] <EricDalquist> well ... how else are we going to get the fitler in all the apps that need it
[17:34:53 EST(-0500)] <EricDalquist> otherwise we start copying this class file everywhere
[17:35:01 EST(-0500)] <athena7> do you think many apps will want a long-term cache filter?
[17:35:03 EST(-0500)] <EricDalquist> and then if we make changes it is a much larger pita to update
[17:35:06 EST(-0500)] <EricDalquist> every portlet
[17:35:08 EST(-0500)] <EricDalquist> and the portal
[17:35:18 EST(-0500)] <EricDalquist> that's close to 10 for 3.1
[17:35:31 EST(-0500)] <athena7> i'm hesitant to put the portal's javascript behind it, since i suspect that schools may need to change it
[17:35:50 EST(-0500)] <EricDalquist> and that is where we need to document things well
[17:35:59 EST(-0500)] <EricDalquist> and/or just not apply it to everything
[17:36:24 EST(-0500)] <EricDalquist> adding comments to the top of files the users may modify about having to change the filename/path when they make changes
[17:36:52 EST(-0500)] <athena7> i'm certainly happy to package the filter in a war
[17:37:01 EST(-0500)] <athena7> right now i'm actually not sure there are any portal files we want to protect
[17:37:30 EST(-0500)] <EricDalquist> what about all of the jquery js and css files?
[17:37:41 EST(-0500)] <athena7> so i think we'd want to include those in the actual webapp?
[17:37:52 EST(-0500)] <athena7> rather than continue to package them in the portal
[17:38:05 EST(-0500)] <EricDalquist> I think we're on different topics (smile)
[17:38:18 EST(-0500)] <athena7> lol, maybe
[17:38:19 EST(-0500)] <athena7> sorry
[17:38:25 EST(-0500)] <athena7> it's been a long week
[17:38:35 EST(-0500)] <EricDalquist> so what are you working on right now ... I'm thinking of a Filter implementation that is included in a webapp like uPortal
[17:38:59 EST(-0500)] <EricDalquist> then mapping is done in the apps web.xml to apply the filter to specific resources included in the webapp to set gzip and caching headers
[17:39:45 EST(-0500)] <athena7> ok, so i did create that filter
[17:40:12 EST(-0500)] <athena7> but also created a separate webapp and dumped in the non-uportal library resources we're currently using - jquery, fluid, etc.
[17:40:23 EST(-0500)] <EricDalquist> ah ok
[17:40:32 EST(-0500)] <EricDalquist> so perhaps in the project we have two child modules
[17:40:35 EST(-0500)] <athena7> so that there would be a shared target for uportal and any portlets to request those resources from - otherwise they won't have shared caches
[17:40:44 EST(-0500)] <EricDalquist> one being a very simple little JAR module with the filter in it
[17:40:52 EST(-0500)] <EricDalquist> just a sec ...
[17:41:01 EST(-0500)] <athena7> sure
[17:52:16 EST(-0500)] <EricDalquist> back
[17:52:35 EST(-0500)] <EricDalquist> ok so the files not having shared caches isn't necessarily bad
[17:52:40 EST(-0500)] <EricDalquist> we have levels of improvement here
[17:52:58 EST(-0500)] <EricDalquist> right now we're at the bottom, each webapp has its own js/css files and they aren't being compressed or cached
[17:53:10 EST(-0500)] <athena7> yes, but it's pretty easy to do the second step at the same time
[17:53:16 EST(-0500)] <EricDalquist> the next step would be each webapp having its down js/css files but gzip and caching them
[17:53:30 EST(-0500)] <EricDalquist> the next would be a central webapp to host them
[17:53:31 EST(-0500)] <EricDalquist> well
[17:53:32 EST(-0500)] <EricDalquist> kind of
[17:53:38 EST(-0500)] <EricDalquist> it adds an external dependency
[17:53:43 EST(-0500)] <EricDalquist> which isn't really easy to add
[17:53:49 EST(-0500)] <EricDalquist> if you grab the bookmarks portlet
[17:54:01 EST(-0500)] <EricDalquist> you need to know that you also need the ResourceProviderPortlet
[17:54:07 EST(-0500)] <EricDalquist> otherwise bookmarks will break
[17:54:26 EST(-0500)] <athena7> the problem is that i think for a lot of institutions, importing in all the dependencies 10 times actually is not going to be considered an option
[17:54:31 EST(-0500)] <athena7> yeah, that's definitely true
[17:54:34 EST(-0500)] <EricDalquist> if you ever change the URL structure or webapp name for ResourceProviderPortlet everything that depends on it would need to be updated
[17:54:51 EST(-0500)] <athena7> for those portlets, it might be reasonable to have this new behavior be toggleable, and default to including the file
[17:54:53 EST(-0500)] <EricDalquist> but at that first level a user only ever imports them 10 times once
[17:55:14 EST(-0500)] <EricDalquist> after that it doesn't matter that they are listed 10 times
[17:55:30 EST(-0500)] <EricDalquist> I'm just thinking longer term if you have a lot of repeat users
[17:55:41 EST(-0500)] <athena7> i think people will still object
[17:56:01 EST(-0500)] <EricDalquist> 1 page load with 20 resource loads and then 1 year of no loading isn't much different than 1 page load with 5 resource loads and then 1 year of no loading
[17:56:05 EST(-0500)] <EricDalquist> yeah
[17:56:08 EST(-0500)] <athena7> i could envision the case of a campus computer cluster, where pretty much any time a user logs in it's the first time they log in with that browser profile
[17:56:09 EST(-0500)] <EricDalquist> people need perspective (wink)
[17:56:26 EST(-0500)] <EricDalquist> true
[17:56:29 EST(-0500)] <athena7> in that case, pretty much any time you sat down at a machine, it'd be the "first" time you saw the portal
[17:56:37 EST(-0500)] <EricDalquist> hrm
[17:56:53 EST(-0500)] <athena7> i guess i'd really like to at least include the new webapp in uportal 3.1, and configure uportal to use it
[17:56:55 EST(-0500)] <EricDalquist> I just don't want to make just using one of our portlets hard because of this
[17:56:59 EST(-0500)] <athena7> right
[17:57:25 EST(-0500)] <EricDalquist> hrm
[17:57:36 EST(-0500)] <athena7> my hope was that we could have a configuration flag somewhere for any portlets that need it that lets people either choose to just use scripts that are part of the webapp, or use the external server
[17:57:43 EST(-0500)] <EricDalquist> yeah
[17:57:52 EST(-0500)] <EricDalquist> I'm trying to think of neat tricks we could use
[17:57:59 EST(-0500)] <EricDalquist> ooo ... one idea
[17:58:16 EST(-0500)] <EricDalquist> in that stand-alone JAR that has our cache header servlet filter
[17:58:22 EST(-0500)] <EricDalquist> we include a little JSP taglib
[17:58:33 EST(-0500)] <athena7> we already have some of that - a lot of the portlets allow you to pick whether you want to import jquery at all or not, since as things stand now, you really don't want to accidentally import it twice (everything breaks)
[17:58:53 EST(-0500)] <EricDalquist> it looks for an init-param in the web.xml for the webapp path of the ResourceServingWebapp
[17:59:29 EST(-0500)] <athena7> hey that's kinda cool (smile)
[17:59:41 EST(-0500)] <athena7> would prevent people from having to actively configure it
[17:59:56 EST(-0500)] <athena7> well
[18:00:04 EST(-0500)] <athena7> i guess you sort of would still
[18:00:06 EST(-0500)] <EricDalquist> you could include resources like: <rs:cached url="/js/jquery/core/1.6/jquery-core-1.6.js"/>
[18:00:16 EST(-0500)] <athena7> yeah
[18:00:25 EST(-0500)] <EricDalquist> when the tag renders it does a cross-context lookup via the servlet APIs for the ResourceServingWebapp
[18:00:37 EST(-0500)] <EricDalquist> if it is there it uses that info to generate the appropriate URL
[18:00:45 EST(-0500)] <athena7> i like it
[18:00:51 EST(-0500)] <EricDalquist> if the lookup fails it just writes out the URL as is prepending the current context path
[18:01:12 EST(-0500)] <athena7> are there any servlet API version limitations on that?
[18:01:12 EST(-0500)] <EricDalquist> it would be easy enough to configure in the uPortal build using the overlay filtering tricks
[18:01:26 EST(-0500)] <EricDalquist> I don't think so
[18:01:43 EST(-0500)] <athena7> sounds great
[18:02:08 EST(-0500)] <EricDalquist> though we would have to test ... there may be the need for a META-INF/context.xml file in Tomcat
[18:02:16 EST(-0500)] <EricDalquist> to enable cross-context lookups for the webapp (sad)
[18:02:27 EST(-0500)] <athena7> ok
[18:02:36 EST(-0500)] <EricDalquist> the other (though slightly slower) option would be for ResourceServingWebapp to expose a simple REST API
[18:02:41 EST(-0500)] <athena7> even if we had to have a configuration flag somewhere - in a properties file, or whatever, it wouldn't be the end of the world
[18:02:50 EST(-0500)] <EricDalquist> so instead of doing ServletCotnext.getContext("/ResourceServingWebapp")
[18:03:05 EST(-0500)] <EricDalquist> it could do a http request
[18:03:06 EST(-0500)] <EricDalquist> oh
[18:03:09 EST(-0500)] <athena7> as you said, it's easy to override with our maven overlays
[18:03:10 EST(-0500)] <EricDalquist> but that would be much more of a pain
[18:03:16 EST(-0500)] <EricDalquist> since then it needs to know the host name to use
[18:03:17 EST(-0500)] <EricDalquist> uhg
[18:03:34 EST(-0500)] <athena7> yeah i guess that's true
[18:03:38 EST(-0500)] <EricDalquist> I think the ServletContext.getContext call is the way to go
[18:03:44 EST(-0500)] <athena7> yeah i'll definitely try it out
[18:03:52 EST(-0500)] <EricDalquist> the result of not having the context.xml file setup right would just be like the ResourceServingWebapp not being avaialble
[18:04:04 EST(-0500)] <EricDalquist> and that context.xml file can easily be added by an overlay
[18:04:11 EST(-0500)] <athena7> sounds reasonable
[18:04:18 EST(-0500)] <EricDalquist> so this project has two modules then
[18:04:26 EST(-0500)] <EricDalquist> a resource-server jar
[18:04:33 EST(-0500)] <EricDalquist> that includes the cache setting Fitler
[18:04:39 EST(-0500)] <EricDalquist> and this JSP tag
[18:04:51 EST(-0500)] <EricDalquist> and a ResourceServingWebapp war
[18:05:09 EST(-0500)] <EricDalquist> that uses the same fitler and also includes a bunch of common JS and CSS files
[18:05:13 EST(-0500)] <EricDalquist> with decent paths
[18:05:30 EST(-0500)] <athena7> excellent
[18:05:31 EST(-0500)] <athena7> (smile)
[18:05:47 EST(-0500)] <athena7> we got a name for this thing for svn? resource-server?
[18:05:50 EST(-0500)] <athena7> i hate naming things
[18:05:58 EST(-0500)] <EricDalquist> I dub it resource-server
[18:06:08 EST(-0500)] <athena7> most excellent, sir eric.
[18:06:16 EST(-0500)] <EricDalquist> with child modules of resource-server-utils
[18:06:22 EST(-0500)] <EricDalquist> and resource-server-webapp
[18:06:26 EST(-0500)] <athena7> great
[18:06:47 EST(-0500)] <athena7> while we're on the topic, how much stuff do we want to gzip in the portal?
[18:06:56 EST(-0500)] <athena7> i'd imagine the css and javascript should be
[18:07:03 EST(-0500)] <EricDalquist> yeah
[18:07:06 EST(-0500)] <athena7> if we really wanted to, we could gzip *.up as well
[18:07:09 EST(-0500)] <EricDalquist> I mean everything could be
[18:07:21 EST(-0500)] <EricDalquist> that might be good just since even with the new theme there is a lot of markup
[18:07:56 EST(-0500)] <athena7> and that will include the whole page, regardless of content, too
[18:08:15 EST(-0500)] <athena7> so if you had a ton of portlets on a page, or whatever
[18:08:48 EST(-0500)] <EricDalquist> yup
[18:09:10 EST(-0500)] <athena7> ok
[18:09:15 EST(-0500)] <athena7> i'll write up a ticket describing all this
[18:09:52 EST(-0500)] <EricDalquist> hrm
[18:10:05 EST(-0500)] <athena7> oh, i guess there's nowhere to put it, huh
[18:10:05 EST(-0500)] <EricDalquist> I'm looking at the ehcache gzip filter and I'm not all that impressed
[18:10:13 EST(-0500)] <EricDalquist> they gzip the whole thing in memory then flush it out
[18:10:18 EST(-0500)] <athena7> ick :/
[18:10:21 EST(-0500)] <EricDalquist> no streaming of the response or anything
[18:10:26 EST(-0500)] <EricDalquist> well
[18:10:30 EST(-0500)] <EricDalquist> just use that for now
[18:10:32 EST(-0500)] <athena7> yeah
[18:10:36 EST(-0500)] <EricDalquist> we can always look at a different option later
[18:10:44 EST(-0500)] <athena7> but that definitely sounds like something that warrants thought
[18:10:53 EST(-0500)] <athena7> particularly if we're zipping up portal html pages
[18:11:19 EST(-0500)] <EricDalquist> yeah
[18:11:27 EST(-0500)] <EricDalquist> and I'd be interested in a 'cache content' flag
[18:11:30 EST(-0500)] <EricDalquist> for our static stuff
[18:11:37 EST(-0500)] <EricDalquist> where it only gziped the first request
[18:11:48 EST(-0500)] <EricDalquist> and teed the output into an in memory cache
[18:12:03 EST(-0500)] <EricDalquist> since really, does it need to gzip the same CSS or JS file upteen thousand times
[18:12:08 EST(-0500)] <athena7> yeah, i think that makes a lot of sense
[18:13:36 EST(-0500)] <athena7> i've elected to stick the minification in the build for now
[18:15:08 EST(-0500)] * bszabo1 (n=bszabo@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[18:15:12 EST(-0500)] * bszabo1 (n=bszabo@wsip-98-174-242-39.ph.ph.cox.net) has left ##uportal
[18:17:01 EST(-0500)] <EricDalquist> actually EhCache has a SimplePageCachingFilter too
[18:17:17 EST(-0500)] <EricDalquist> you could apply that after the gzip fitler to .js and .css resources
[18:17:22 EST(-0500)] <EricDalquist> and it would cache the gziped content
[18:18:24 EST(-0500)] <EricDalquist> actually apparently the SimplePageCachingFilter also gzips content
[18:18:43 EST(-0500)] <EricDalquist> wouldn't want to use that for portal URLs
[18:18:51 EST(-0500)] <EricDalquist> but for the js and css resources it would be very good
[18:19:00 EST(-0500)] <athena7> actually i was wondering if ehcache had something we could use
[18:19:08 EST(-0500)] <athena7> i'd seen a few references but hadn't had time to look yet
[18:19:11 EST(-0500)] <athena7> that's great to know (smile)
[18:19:27 EST(-0500)] <athena7> so applying the page caching one to js and css, and the regular gzip to the portal urls
[18:19:54 EST(-0500)] <EricDalquist> heading home ... back on in a few hours
[18:31:57 EST(-0500)] * lennard1 (n=sparhk@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[19:12:38 EST(-0500)] * lennard1 (n=sparhk@wsip-98-174-242-39.ph.ph.cox.net) has left ##uportal
[19:42:12 EST(-0500)] * athena7 (n=athena7@ip68-230-77-209.ph.ph.cox.net) has joined ##uportal
[19:53:27 EST(-0500)] * apetro (n=apetro@ip68-3-207-51.ph.ph.cox.net) has joined ##uportal