[00:27:44 EDT(-0400)] * Sememmon (n=Sememmon@ip70-190-32-223.ph.ph.cox.net) has joined ##uportal
[00:40:26 EDT(-0400)] * lennard1 (n=sparhk@ip68-98-56-21.ph.ph.cox.net) has joined ##uportal
[01:10:07 EDT(-0400)] * lennard1 (n=sparhk@ip68-98-56-21.ph.ph.cox.net) has left ##uportal
[07:53:41 EDT(-0400)] * athena (n=athena@99.129.100.66) has joined ##uportal
[08:27:19 EDT(-0400)] * fj4000 (n=Main@CPE0018f85ab63e-CM001692f5798c.cpe.net.cable.rogers.com) has joined ##uportal
[08:51:27 EDT(-0400)] * anastasiac (n=stasia@142.150.154.189) has joined ##uportal
[08:57:59 EDT(-0400)] * colinclark (n=colin@CPE0014d13fa0bb-CM0018c0c60930.cpe.net.cable.rogers.com) has joined ##uportal
[08:58:21 EDT(-0400)] * colinclark_ (n=colin@bas2-toronto09-1176130727.dsl.bell.ca) has joined ##uportal
[09:34:58 EDT(-0400)] * lennard1 (n=sparhk@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[10:09:44 EDT(-0400)] * SusanB (i=user@susan-x200.its.yale.edu) has joined ##uportal
[10:14:12 EDT(-0400)] * colinclark (n=colin@bas2-toronto09-1176130727.dsl.bell.ca) has joined ##uportal
[10:40:21 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[10:42:05 EDT(-0400)] * jessm (n=Jess@c-71-232-3-4.hsd1.ma.comcast.net) has joined ##uportal
[10:49:38 EDT(-0400)] <athena> EricDalquist: i'm having some really weird problems with setting the new uportal plugin to <inherited>false</inherited
[10:49:45 EDT(-0400)] <athena> wasn't sure if you'd ever run into something like it
[10:49:51 EDT(-0400)] <EricDalquist> what are you running into/
[10:50:01 EDT(-0400)] <athena> basically it seems like none of the <configuration/> section is applied when i turn off the inherited prop
[10:50:11 EDT(-0400)] <EricDalquist> weird
[10:50:15 EDT(-0400)] <EricDalquist> what version of maven are you using?
[10:50:24 EDT(-0400)] <athena> 2.0.10
[10:50:42 EDT(-0400)] <EricDalquist> that is strange
[10:50:47 EDT(-0400)] <EricDalquist> though
[10:51:11 EDT(-0400)] <EricDalquist> having it be inherited may not be bad if it doesn't bind to any of the normal lifecycles
[10:51:24 EDT(-0400)] <EricDalquist> its just dangerous if you have something in the parent that like binds to clean
[10:51:32 EDT(-0400)] <athena> it doesn't, but it makes it slow
[10:51:37 EDT(-0400)] <EricDalquist> ah
[10:51:52 EDT(-0400)] <EricDalquist> I've had a lot of luck in the maven irc channel
[10:52:02 EDT(-0400)] <EricDalquist> http://maven.apache.org/community.html
[10:52:02 EDT(-0400)] <athena> ok, maybe i'll try that
[10:52:05 EDT(-0400)] <athena> thanks
[10:52:11 EDT(-0400)] <athena> i don't know if it's something i did wrong, or what
[11:12:48 EDT(-0400)] * awills (n=awills@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[11:14:45 EDT(-0400)] * michelled (n=team@142.150.154.193) has joined ##uportal
[11:20:34 EDT(-0400)] <athena> i'm a little worried that this is actually a maven problem
[11:20:39 EDT(-0400)] <athena> i don't see what it wouldnt' work
[11:20:40 EDT(-0400)] <athena> :/
[11:21:08 EDT(-0400)] <EricDalquist> try mvn 2.1?
[11:21:30 EDT(-0400)] <athena> yeah i guess i could try that
[11:21:39 EDT(-0400)] <athena> sounds like cris got it working w/ uportal okO?
[11:22:18 EDT(-0400)] <EricDalquist> yeah it should work
[11:22:23 EDT(-0400)] <EricDalquist> and I'd be fine requiring that for 3.2
[11:23:00 EDT(-0400)] <athena> we'll see if it makes a difference
[11:29:23 EDT(-0400)] <athena> argh
[11:29:26 EDT(-0400)] <athena> that doesn't help
[11:29:58 EDT(-0400)] <EricDalquist> any luck on #maven?
[11:30:52 EDT(-0400)] <athena> nope
[11:31:03 EDT(-0400)] <athena> don't know if anyone's really around
[11:31:25 EDT(-0400)] <EricDalquist> ah
[11:31:37 EDT(-0400)] <EricDalquist> if you want to pastebin a patch of your changes I can look
[11:32:22 EDT(-0400)] <athena> yeah maybe another pair of eyes will help, thanks
[11:32:49 EDT(-0400)] <athena> <plugin>
[11:32:49 EDT(-0400)] <athena> <artifactId>maven-uportal-plugin</artifactId>
[11:32:50 EDT(-0400)] <athena> <groupId>org.jasig.portal</groupId>
[11:32:50 EDT(-0400)] <athena> <version>1.0.0-SNAPSHOT</version>
[11:32:50 EDT(-0400)] <athena> <inherited>false</inherited>
[11:32:51 EDT(-0400)] <athena> <configuration>
[11:32:52 EDT(-0400)] <athena> <artifactId>uportal-ear</artifactId>
[11:32:54 EDT(-0400)] <athena> <artifactGroupId>org.jasig.portal</artifactGroupId>
[11:32:56 EDT(-0400)]

<athena> <artifactVersion>$

Unknown macro: {uportal.version}

</artifactVersion>

[11:32:58 EDT(-0400)] <athena> <removeExistingDirectories>true</removeExistingDirectories>
[11:33:00 EDT(-0400)] <athena> <extractWars>true</extractWars>
[11:33:02 EDT(-0400)] <athena> </configuration>
[11:33:04 EDT(-0400)] <athena> </plugin>
[11:33:06 EDT(-0400)] <athena> ack
[11:33:08 EDT(-0400)] <athena> http://uportal.pastebin.com/m4857512d
[11:33:08 EDT(-0400)] <EricDalquist> lol
[11:33:10 EDT(-0400)] <athena> that was what i actually meant to paste
[11:33:12 EDT(-0400)] <athena> first section works, second doesn't
[11:33:52 EDT(-0400)] <EricDalquist> so with the second it gets called but no config data shows up?
[11:34:20 EDT(-0400)] <athena> exactly
[11:34:42 EDT(-0400)] <EricDalquist> weird
[11:34:48 EDT(-0400)] <athena> i've seen some references to configuration data not being available in an execution block, but i'm not using those
[11:34:53 EDT(-0400)] <EricDalquist> I guess I need to learn more about writing maven plugins
[11:35:08 EDT(-0400)] <athena> apparently the execution blocks only work when you're binding to a maven lifecycle phase, but not from the command line
[11:35:32 EDT(-0400)] <EricDalquist> ah
[11:36:03 EDT(-0400)] <athena> but this really should work
[11:36:34 EDT(-0400)] <athena> and i don't think there's a maven phase it would actually be appropriate to bind this to
[11:36:40 EDT(-0400)] <EricDalquist> this is in the root pom?
[11:37:57 EDT(-0400)] * holdorph (n=holdorph@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[11:38:50 EDT(-0400)] <athena> yeah
[11:39:22 EDT(-0400)] <athena> if we put it in the uportal-ear pom i'm not sure the goal would be available from the root
[11:44:31 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined ##uportal
[11:56:03 EDT(-0400)] <athena> ok, does <inherited/> just not do what i think it does?
[11:56:13 EDT(-0400)] <athena> it looks like this plugin is being run for the child modules
[12:08:34 EDT(-0400)] * jessm (n=Jess@c-71-232-3-4.hsd1.ma.comcast.net) has joined ##uportal
[12:32:01 EDT(-0400)] * invisibill (i=80876350@gateway/web/ajax/mibbit.com/x-cab457e550169a1e) has joined ##uportal
[12:33:53 EDT(-0400)] <invisibill> Greetings EircDalquist: what version / product of hyperion are you using for the collected statistics data in the 3.1 uportal? we're looking for a tool to use for analysis.
[12:42:17 EDT(-0400)] * Sememmon (n=Sememmon@uni1.unicon.net) has joined ##uportal
[13:12:25 EDT(-0400)] <awills> so dealing with the data for UP_SS_USER_ATTS through the uP APIs based on UserPreferences & ssup/tsup is taking a massively disproportionate amount of time to troubleshoot

[13:12:36 EDT(-0400)] <EricDalquist>

[13:12:53 EDT(-0400)] <EricDalquist> makes you wish there were real DAOs huh
[13:13:05 EDT(-0400)] <EricDalquist> invisibill: I don't know, I'm not the person directly using it
[13:13:14 EDT(-0400)] <EricDalquist> if you email that question to uportal-user I can point my manager to it
[13:13:25 EDT(-0400)] <awills> yeah this part of the framework needs an overhaul
[13:13:31 EDT(-0400)] <EricDalquist> heh
[13:13:32 EDT(-0400)] <EricDalquist> yeah
[13:13:44 EDT(-0400)] <EricDalquist> user, layout, attribute storage is all SCARY
[13:13:51 EDT(-0400)] * jessm (n=Jess@c-71-232-3-4.hsd1.ma.comcast.net) has joined ##uportal
[13:13:57 EDT(-0400)] <EricDalquist> also we are still working on incubating the aggregation tool but that likely won't happen for another few weeks

[13:16:14 EDT(-0400)] <awills> SCARY is accurate... e.g., it traverses the DOM using calls like "myNode.getFirstChild().getFirstChild()" which throws NPE if there's ignorable whitespace

[13:16:27 EDT(-0400)] <EricDalquist> yup
[13:16:40 EDT(-0400)] <awills> here's the impl of USER_ATTS atm: http://uportal.pastebin.com/d6a7eb3f5
[13:17:07 EDT(-0400)] <EricDalquist>

[13:17:23 EDT(-0400)] <awills> 91 lines of mostly cruft
[13:17:28 EDT(-0400)] <EricDalquist> yup
[13:18:02 EDT(-0400)] <EricDalquist> my guess is if we had the time to do a bit of redesign and reimplement the rendering pipe and layout/attr stores we could drop tens of thousands of LOC{color}
[13:18:09 EDT(-0400)] <EricDalquist> and have a faster portqal
[13:18:54 EDT(-0400)] <awills> i think you're right... multiple 10k LOC
[13:19:09 EDT(-0400)] <EricDalquist> oh well
[13:19:25 EDT(-0400)] <EricDalquist> maybe I can start documenting some of my ideas and things we had done in the sandbox in the next month or two
[13:19:35 EDT(-0400)] <EricDalquist> there were some neat ideas there
[13:20:39 EDT(-0400)] <awills> i bet we could accomplish much even w/in the existing set of interfaces
[13:21:02 EDT(-0400)] <EricDalquist> oh yeah
[13:21:13 EDT(-0400)] <EricDalquist> I don't think a new impl would be that much different from the existing APIs
[13:21:35 EDT(-0400)] <invisibill> Thanks EricDalquist. I send it along to the uportal-user list.
[13:21:36 EDT(-0400)] <EricDalquist> but for now I have to come up with a bookmarkable URL system for uPortal
[13:21:49 EDT(-0400)] <EricDalquist> I think I'm going to build on your existing tab-fname work
[13:22:18 EDT(-0400)] <awills> though we could enhance the APIs massively with a few little niceties like – i don't know – a UserPreferences.clear() method
[13:23:07 EDT(-0400)] <EricDalquist> hah
[13:23:27 EDT(-0400)] <EricDalquist> well abstracting all that stuff out into DAOs that have more standard CRUD operations would be huge
[13:23:43 EDT(-0400)] <EricDalquist> it is so hard for a lot of it because the data access logic is embedded with the actual functional logic of the store
[13:24:11 EDT(-0400)] <EricDalquist> plus since that old stuff has no referential integrity it is REALLY easy to break the portal{color}
[13:25:42 EDT(-0400)] <awills> well i have this layout doc importing and rendering appropriately in the portal, afaik: http://uportal.pastebin.com/d9f6cb2d
[13:26:00 EDT(-0400)] <EricDalquist> great
[13:26:24 EDT(-0400)] <EricDalquist> once you get that committed and before it is released I'll look into supporting preferences for transient portlets
[13:26:36 EDT(-0400)] <awills> great
[13:27:06 EDT(-0400)] <EricDalquist> I'm thinking it will just look like: <entry entity="" channel="jasig-test-portlet" name="">
[13:27:11 EDT(-0400)] <EricDalquist> so that's easy
[13:27:11 EDT(-0400)] <awills> and fyi, the portlets I moved on the Welcome fragment before export are still moved after import

[13:27:21 EDT(-0400)] <EricDalquist> great
[13:27:26 EDT(-0400)] <EricDalquist> what about tab level moves?
[13:27:42 EDT(-0400)] <EricDalquist> so rearrange some tabs, delete one, change ones name
[13:27:44 EDT(-0400)] <awills> like, reodering tabs?
[13:27:50 EDT(-0400)] <EricDalquist> all of those create dlm nodes
[13:27:54 EDT(-0400)] <EricDalquist> yeah
[13:27:59 EDT(-0400)] <awills> k
[13:30:08 EDT(-0400)] <dstn> EricDalquist, I am using the ajax support library to make an ajax request when the page loads and I'm getting the following: http://uportal.pastebin.com/m1225e5dc any ideas?
[13:30:45 EDT(-0400)] <EricDalquist> hrm
[13:31:05 EDT(-0400)] <EricDalquist> something is writing to the response before you try to send the redirect
[13:31:48 EDT(-0400)] <EricDalquist> that is a pita to track down
[13:32:08 EDT(-0400)] <EricDalquist> I think setting the content type or writing to the output stream of the response makes it invalid to send a redirect with
[13:35:21 EDT(-0400)] <dstn> hmm...I wonder if the interceptor has anything to do with that
[13:35:35 EDT(-0400)] <dstn> thanks for the pointers, I'll try to track it down
[13:35:39 EDT(-0400)] <EricDalquist> yup
[13:41:34 EDT(-0400)] <awills> so when I moved tabs around and exported, i got duplicates of the preferences entries (commented at bottom): http://uportal.pastebin.com/d58d9cadf
[13:42:06 EDT(-0400)] <awills> which wouldn't re-import, but when i commented them the document imported
[13:42:14 EDT(-0400)] <EricDalquist> interesting
[13:42:42 EDT(-0400)] <EricDalquist> it could be that portlet preferences are getting duplicated in the db when a tab moves
[13:43:24 EDT(-0400)] <awills> but none of what I did actually tested what you asked about, since it looks like i really need to move a DLM frag... which will require permissions chanegs first O.o
[13:44:21 EDT(-0400)] <EricDalquist> ah yeah
[13:45:45 EDT(-0400)] <dstn> turns out it was the interceptor: org.springframework.web.portlet.handler.ParameterMappingInterceptor
[13:45:56 EDT(-0400)] <EricDalquist> ah
[13:46:11 EDT(-0400)] <EricDalquist> that makes sense
[13:46:18 EDT(-0400)] <EricDalquist> it calls setRenderParam before the redirect
[13:50:07 EDT(-0400)] <awills> so fragment owners don't seem to get the "Customize" link O.o
[13:50:21 EDT(-0400)] <EricDalquist> yeah
[13:50:30 EDT(-0400)] <EricDalquist> I meant to check on that after the email thread on uportal-user
[13:50:36 EDT(-0400)] <EricDalquist> that would appear to be a bug
[13:51:17 EDT(-0400)] <awills> 3.1 theme is beautiful though

[13:51:27 EDT(-0400)] <EricDalquist>

[13:52:06 EDT(-0400)] <awills> i've got a call coming up... be back in a few
[13:52:12 EDT(-0400)] <EricDalquist> k
[13:54:24 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined ##uportal
[14:11:39 EDT(-0400)] <dstn> is there any real sure way of avoiding perm gen space running out during repeated deployments during development without restarting
[14:46:44 EDT(-0400)] <EricDalquist> yeah ... we need to figure out why uPortal doesn't undeploy completely
[14:46:58 EDT(-0400)] <EricDalquist> so it is really tricky to get right
[14:48:17 EDT(-0400)] <EricDalquist> the danger is if ANY class from a classloader other than the webapp's classloader hold a reference to a class in the webapp's classloader then NONE of the classes (or static data) in that webapps classloader can be unloaded
[14:48:20 EDT(-0400)] <EricDalquist> is that clear enough

[15:03:28 EDT(-0400)] <athena> does https://www.ja-sig.org/svn/sandbox/maven-uportal-plugin/trunk sound like a good starting place?
[15:41:41 EDT(-0400)] <EricDalquist> athena: +1
[15:50:28 EDT(-0400)] <dstn> sooooo is there a way to trigger a callback to a portlet when its removed from the layout
[15:50:48 EDT(-0400)] <EricDalquist> um, I think there is one
[15:50:56 EDT(-0400)] <EricDalquist> well
[15:51:00 EDT(-0400)] <EricDalquist> not to the portlet itself
[15:51:08 EDT(-0400)] <EricDalquist> but there is to the internal portlet handling code
[15:51:18 EDT(-0400)] <EricDalquist> you looking for a way to do cleanup?
[15:51:29 EDT(-0400)] <dstn> ya, for an external store
[15:51:34 EDT(-0400)] <holdorph> what kind of cleanup do you need to do?
[15:51:54 EDT(-0400)] <EricDalquist> yeah, not sure there is an easy way to do that
[15:52:04 EDT(-0400)] <EricDalquist> the spec doesn't provide any sort of notification like
[15:52:05 EDT(-0400)] <EricDalquist> that
[15:52:08 EDT(-0400)] <holdorph> what kind of external store are you keeping open?
[15:52:11 EDT(-0400)] <EricDalquist> not sure if it would be possible in 2.x
[15:52:20 EDT(-0400)] <holdorph> with a specific portal event maybe
[15:52:25 EDT(-0400)] <dstn> a user adds a calendar portlet and adds a bunch of preferences, calendars and stuff, then deletes it...looking to clean up the database stuff
[15:52:56 EDT(-0400)] <dstn> ok, just thought I'd ask
[15:52:59 EDT(-0400)] <dstn> didn't think there was
[15:53:37 EDT(-0400)] <holdorph> ah, i understand now.
[15:53:49 EDT(-0400)] <holdorph> but yeah, the simple answer is, unfortunately, 'no'
[15:55:44 EDT(-0400)] <dstn>

[15:56:07 EDT(-0400)] <holdorph> great use case for portal specific events though.
[15:56:25 EDT(-0400)] <holdorph> in the JSR 286 spec
[15:57:10 EDT(-0400)] <EricDalquist> yeah
[16:00:58 EDT(-0400)] <athena> if you had it in the same database you could manually set a trigger, i suppose
[16:01:08 EDT(-0400)] <athena> that seems sort of painful though
[16:01:15 EDT(-0400)] <EricDalquist> yeaj
[16:01:20 EDT(-0400)] <EricDalquist> and would likely be a very complex trigger
[16:02:40 EDT(-0400)] <athena> yeah
[16:02:41 EDT(-0400)] <athena> icky
[16:11:51 EDT(-0400)] * awills1 (n=awills@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[16:21:17 EDT(-0400)] <dstn> suppose I could trigger an ajax callback to a controller
[16:22:05 EDT(-0400)] <holdorph> how would the ajax know it's being removed, versus the person is just leaving the page normally?
[16:23:17 EDT(-0400)] * tsnfoo (n=tsnfoo@wso-mbp15.test.denison.edu) has joined ##uportal
[16:24:56 EDT(-0400)] <dstn> would have to figure out how to bind it to the remove click
[16:25:12 EDT(-0400)] <dstn> would be specific to the uportal layout
[16:25:27 EDT(-0400)] <EricDalquist> the more reasonable thing if this is a serious concern would be a periodic purge process
[16:25:37 EDT(-0400)] <EricDalquist> I question how serious of a concern it is though
[16:25:44 EDT(-0400)] <EricDalquist> its only like 1k of data per user
[16:25:46 EDT(-0400)] <EricDalquist> or less
[16:25:55 EDT(-0400)] <dstn> probably not
[16:26:04 EDT(-0400)] <dstn> just being picky

[16:26:08 EDT(-0400)] <EricDalquist>

[16:27:18 EDT(-0400)] <dstn> do portlet preferences get cleaned up?
[16:27:31 EDT(-0400)] <dstn> in 3.1 that is
[16:27:53 EDT(-0400)] <EricDalquist> I think so
[16:29:13 EDT(-0400)] <EricDalquist> http://developer.jasig.org/source/browse/jasigsvn/uPortal/trunk/uportal-impl/src/main/java/org/jasig/portal/channels/portlet/SpringPortletChannelImpl.java?r=45660#l584
[16:29:14 EDT(-0400)] <EricDalquist> yup
[16:29:45 EDT(-0400)] <EricDalquist> the TODO on line 596 should be removed since windows are not persisted anywhere
[16:29:58 EDT(-0400)] <EricDalquist> the only benefit there would be a few bytes of memory
[16:30:06 EDT(-0400)] <EricDalquist> which is cleaned up when the user's session ends
[16:32:15 EDT(-0400)] <dstn> sweet
[16:37:46 EDT(-0400)] * SusanB (i=user@susan-x200.its.yale.edu) has left ##uportal
[18:16:22 EDT(-0400)] <holdorph> athena, dstn i'm updating some literature I have giving about 3 bullet points worth of info on different portlets that ship with uportal 3.1. Can you guys tell me which technologies you use in the weather and calendar portlets
[18:16:46 EDT(-0400)] <athena> just so you know, neither of those actually ship with uPortal 3.1
[18:17:07 EDT(-0400)] <athena> the calendar portlet uses spring portletmvc and hibernate
[18:17:17 EDT(-0400)] <athena> calendar adapters use things like ical4j,caldav4j, and rome
[18:17:20 EDT(-0400)] <holdorph> oh, i guess they're just mockups. regardless they are jasig and the literature is still useful
[18:17:25 EDT(-0400)] <athena> yeah
[18:17:35 EDT(-0400)] <athena> the weather portlet uses spring portletmvc as well, i believe
[18:17:45 EDT(-0400)] <athena> the "weather portlet" is a screenshot of the real weather portlet
[18:18:15 EDT(-0400)] <athena> and the calendar is unrelated - it's just the jQuery calendar plugin, which by itself makes a decent mini-month calendar widget
[18:18:16 EDT(-0400)] <holdorph> so what is the calendar one. it appears to be a real widget
[18:18:19 EDT(-0400)] <athena> yeah, it is
[18:18:25 EDT(-0400)] <athena> just the jQuery UI calendar widget
[18:18:29 EDT(-0400)] <holdorph> i c
[18:18:48 EDT(-0400)] <athena> i think it's a CWebProxy channel
[18:19:04 EDT(-0400)] <holdorph> i know why we might not ship the weather portlet because of the accuweather license.
[18:19:11 EDT(-0400)] <holdorph> but why not ship the calendar one?
[18:19:22 EDT(-0400)] <athena> because it still hasn't had a real release, mostly
[18:19:31 EDT(-0400)] <athena> the database really needs to be refactored
[18:19:37 EDT(-0400)] <athena> once that happens i'd be fine with distributing it
[18:20:10 EDT(-0400)] <athena> i'd really like the data to be keyed by a calendar set id
[18:20:23 EDT(-0400)] <athena> right now all calendar items are just keyed to the user id, which isn't really ideal
[18:20:44 EDT(-0400)] <athena> i'm sort of wondering whether it makes sense to not distribute the weather portlet
[18:20:57 EDT(-0400)] <athena> i mean, is the license really more restrictive than the google api?
[18:21:35 EDT(-0400)] <holdorph> yes
[18:21:54 EDT(-0400)] <athena> yeah, i know they asked commercial entities to check in first
[18:21:57 EDT(-0400)] <holdorph> it was extremely clear about not being allowed to be used by a NOT-non-profit org
[18:22:02 EDT(-0400)] <holdorph> without permission, yup.
[18:22:03 EDT(-0400)] <athena> ah ok
[18:22:04 EDT(-0400)] <athena> yeah
[18:22:14 EDT(-0400)] <athena> so what's the current story w/ the google APIs?
[18:22:21 EDT(-0400)] <athena> doesn't the site have to be publicly accessible?
[18:22:38 EDT(-0400)] <holdorph> the javascript is pulled from their server, and it requires an API key, keyed to the host that served the html
[18:22:59 EDT(-0400)] <holdorph> so beyond localhost:8080, it won't work unless you go back to google and re-agree to their terms
[18:23:18 EDT(-0400)] <athena> ah! good point
[18:23:24 EDT(-0400)] <athena> sounds good to me

[18:23:44 EDT(-0400)] <athena> anyway, i'm glad we at least have the screenshot on the page
[18:23:51 EDT(-0400)] <athena> give people a hint that the weather portlet is available, at least
[18:24:11 EDT(-0400)] <holdorph> i'd be in favor of distributing the weather portlet with the accuweather feed turned off by default. to make it easier to incorporate, once they 'agreement' was given
[18:24:19 EDT(-0400)] <athena> that sounds reasonable as well
[18:24:41 EDT(-0400)] <athena> so for the calendar portlet, i think that dwills might be doing some import/export work for it in the near future
[18:24:52 EDT(-0400)] <athena> which would make it a lot easier to get the database fixed up
[18:31:56 EDT(-0400)] * awills (n=awills@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[20:45:52 EDT(-0400)] * lennard1 (n=sparhk@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[20:49:37 EDT(-0400)] * Sememmon (n=Sememmon@ip70-190-32-223.ph.ph.cox.net) has joined ##uportal
[21:20:08 EDT(-0400)] * lennard1 (n=sparhk@wsip-98-174-242-39.ph.ph.cox.net) has left ##uportal
[23:09:40 EDT(-0400)] * lennard1 (n=sparhk@ip68-98-56-21.ph.ph.cox.net) has joined ##uportal