uPortal IRC Logs-2010-08-23

Owned by Apereo Infrastructure
Last updated: Aug 23, 2010Version comment

[09:03:10 CDT(-0500)] <EricDalquist> testing
[09:04:38 CDT(-0500)] * Topic is 'http://uportal.pastebin.com/ - http://www.ja-sig.org/wiki/display/UPC/uportal+IRC+Logs' set by EricDalquist on 11:32:13 CST(-0600)
[12:30:57 CDT(-0500)] <EricDalquist> first look at the new MyUW UI provided by Unicon ... very nice
[12:32:27 CDT(-0500)] <awills> where? (haven't seen it)
[12:35:33 CDT(-0500)] <EricDalquist> on my desktop so far (smile)
[12:35:39 CDT(-0500)] <EricDalquist> working on the 3.2.2 merge
[12:35:43 CDT(-0500)] <EricDalquist> and part of our upgrade is a new UW
[12:35:45 CDT(-0500)] <EricDalquist> UI
[12:35:53 CDT(-0500)] <EricDalquist> so merge is complete, UI is in place
[12:36:00 CDT(-0500)] <EricDalquist> now to get our local quickstart data put together
[12:37:33 CDT(-0500)] <awills> cool... i hope you'll preserve the demo feature
[12:37:43 CDT(-0500)] <EricDalquist> of course
[12:38:14 CDT(-0500)] <awills> showed off your portal, in fact, at texas z&m last week
[12:38:19 CDT(-0500)] <EricDalquist> unfortunately I'm having to export our layout owner's .user, .layout, & .profile entities from prod
[12:38:21 CDT(-0500)] <awills> er, a&m
[12:38:32 CDT(-0500)] <EricDalquist> and since I don't want everyone that's 3 exports per fragment
[12:38:56 CDT(-0500)] <EricDalquist> and since we use a clustered ehcache config there is a constant 45 second over head to running the export script
[12:38:56 CDT(-0500)] <awills> don't want to use included users file?
[12:39:04 CDT(-0500)] <EricDalquist> oh yeah (tongue)
[12:39:06 CDT(-0500)] <EricDalquist> duh
[13:10:26 CDT(-0500)] <EricDalquist> athena: I can't remember did the new CMS-lite portlet make it into 3.2.2?
[13:10:39 CDT(-0500)] <athena> don't think so
[13:10:48 CDT(-0500)] <EricDalquist> I'm assuming it will work in 3.2.2 though
[13:10:52 CDT(-0500)] <EricDalquist> it just needs the config mode
[13:11:01 CDT(-0500)] <athena> yes
[13:11:04 CDT(-0500)] <athena> should work fine
[13:11:05 CDT(-0500)] <athena> a
[13:11:10 CDT(-0500)] <athena> aside from the channel import issue
[13:12:05 CDT(-0500)] <EricDalquist> ah yeah
[13:12:21 CDT(-0500)] <EricDalquist> well I may end up figuring out how to fix that issue then (tongue)
[13:12:27 CDT(-0500)] <athena> oh that'd be awesome
[13:12:35 CDT(-0500)] <EricDalquist> awills: do you have any thoughts?
[13:12:39 CDT(-0500)] <athena> i think the plan was to just rewrite the import job to use the channel publishing service, right?
[13:12:45 CDT(-0500)] <EricDalquist> right
[13:12:49 CDT(-0500)] <EricDalquist> does that exist in 3.2?
[13:12:52 CDT(-0500)] <athena> yep
[13:12:55 CDT(-0500)] <EricDalquist> ok
[13:12:56 CDT(-0500)] <EricDalquist> great
[13:12:56 CDT(-0500)] <athena> hasn't changed since then either, i don't think
[13:13:01 CDT(-0500)] <athena> so i think that should work out well
[13:13:09 CDT(-0500)] <athena> and be straightforward for someone who understands crn better
[13:13:25 CDT(-0500)] <EricDalquist> heh
[13:13:38 CDT(-0500)] <EricDalquist> I foresee "fun" getting the html blob out of the .channel file
[13:14:46 CDT(-0500)] <athena> hmm, really?
[13:15:05 CDT(-0500)] <athena> is there no way to just treat the nodes as text?
[13:15:06 CDT(-0500)] <EricDalquist> I'm not sure how crn handles CDATA
[13:15:15 CDT(-0500)] <athena> ah
[13:15:24 CDT(-0500)] <EricDalquist> well it parses the whole file into an XML Document
[13:15:27 CDT(-0500)] <athena> yeah
[13:15:28 CDT(-0500)] <athena> hmm
[13:15:33 CDT(-0500)] <EricDalquist> so we need to make sure that all the content isn't parsed
[13:15:36 CDT(-0500)] <EricDalquist> and just kept as a string
[13:15:39 CDT(-0500)] <athena> yeah
[13:15:41 CDT(-0500)] <athena> makes sense
[13:15:43 CDT(-0500)] <EricDalquist> CDATA is the way to go I think
[13:15:49 CDT(-0500)] <athena> yes
[13:15:53 CDT(-0500)] <EricDalquist> but I have no idea how that's handled
[13:15:59 CDT(-0500)] <EricDalquist> well I'll deal with it when I get there (smile)
[13:15:59 CDT(-0500)] <athena> though that does raise some import/export issues
[13:16:08 CDT(-0500)] <athena> like how do we make sure stuff is appropriately exported as CDATA?
[13:16:33 CDT(-0500)] <athena> and does the import job strip out the CDATA part?
[13:16:57 CDT(-0500)] <EricDalquist> right
[13:17:31 CDT(-0500)] <EricDalquist> I'm wondering what would happen on export right now
[13:17:40 CDT(-0500)] <EricDalquist> like would it be one bug XML escaped string?
[13:18:26 CDT(-0500)] <athena> good question
[13:18:30 CDT(-0500)] <athena> i have no idea (smile)
[13:36:17 CDT(-0500)] <awills> the CDATA handling should be the same as dom4j
[17:18:23 CDT(-0500)] <awills> has anyone ever seen a subversion error like this? "svn: OPTIONS of [...]: SSL handshake failed: SSL error: bad decompression ([...])"
[17:19:05 CDT(-0500)] <awills> I get it every time i try to use the client on to access this server (not Jasig), though I can view it with a browser
[17:20:43 CDT(-0500)] <holdorph> sounds like something we debugged inside of unicon with respect to some ubuntu linux svn/ssl libraries
[17:20:49 CDT(-0500)] <holdorph> but you're on windows so i don't know