fluid-work IRC Logs-2009-07-20

[07:53:37 EDT(-0400)] * heidi_ (n=thesumme@70.31.82.166) has joined #fluid-work
[08:44:30 EDT(-0400)] * Justin_o (n=Justin@142.150.154.171) has joined #fluid-work
[09:08:33 EDT(-0400)] * athena (n=athena@adsl-75-58-122-144.dsl.wlfrct.sbcglobal.net) has joined #fluid-work
[09:24:03 EDT(-0400)] * fj4000 (n=Jacob@142.150.154.106) has joined #fluid-work
[09:26:13 EDT(-0400)] * anastasiac (n=stasia@142.150.154.189) has joined #fluid-work
[09:26:52 EDT(-0400)] * laurel (n=laurel@dsl-207-112-77-116.tor.primus.ca) has joined #fluid-work
[09:32:21 EDT(-0400)] * anastasiac (n=team@142.150.154.189) has joined #fluid-work
[09:42:53 EDT(-0400)] * yura (n=yura@142.150.82.114) has joined #fluid-work
[10:06:51 EDT(-0400)] * laurel (n=laurel@dsl-207-112-77-116.tor.primus.ca) has joined #fluid-work
[10:08:23 EDT(-0400)] * laurel (n=laurel@dsl-207-112-77-116.tor.primus.ca) has joined #fluid-work
[10:13:56 EDT(-0400)] <yura> hi guys, does everybody have a commit access to a scratchpad?
[10:14:54 EDT(-0400)] <Justin_o> yura: hello, um anyone who has access to incubator does
[10:15:53 EDT(-0400)] <yura> oh i see, I think I used to be able to commit to sandbox before it was renamed, no it seems like my login and password don't work
[10:16:35 EDT(-0400)] <Justin_o> really... but you have been committing to incubator?
[10:17:30 EDT(-0400)] <yura> I m not sure if I did, maybe only when Michelle asked me to test permissions
[10:17:33 EDT(-0400)] * laurel (n=laurel@dsl-207-112-77-116.tor.primus.ca) has joined #fluid-work
[10:17:58 EDT(-0400)] <Justin_o> oh... okay... anastasiac might be able to help you, but she is on a call at the moment
[10:18:15 EDT(-0400)] <yura> oh ok
[10:18:24 EDT(-0400)] <yura> ill bug her then once she has time
[10:23:47 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[10:32:18 EDT(-0400)] * Justin_o (n=Justin@142.150.154.171) has left #fluid-work
[10:45:17 EDT(-0400)] * fj4000 (n=Jacob@142.150.154.106) has joined #fluid-work
[10:45:54 EDT(-0400)] * sgithens342f (n=sgithens@149-166-143-211.dhcp-in.iupui.edu) has joined #fluid-work
[11:03:09 EDT(-0400)] * michelled (n=team@142.150.154.193) has joined #fluid-work
[11:08:52 EDT(-0400)] * colinclark (n=colin@70.26.85.109) has joined #fluid-work
[11:09:08 EDT(-0400)] * Justin_o (n=Justin@142.150.154.171) has joined #fluid-work
[11:09:32 EDT(-0400)] <colinclark> yura: Hey, how's it going?
[11:09:39 EDT(-0400)] <colinclark> We're having a little dev check-in meeting in Connect if you can make it.
[11:09:48 EDT(-0400)] <colinclark> Our goal had been an end-to-end demo, but it was a bit optimistic.
[11:10:00 EDT(-0400)] <colinclark> So instead, we'll catch each other up real quick on our recent work, then get back to it.
[11:42:00 EDT(-0400)] * jsilvaa (n=jsilva@142.150.82.73) has joined #fluid-work
[12:04:59 EDT(-0400)] <jamon> anastasiac: ping
[12:07:38 EDT(-0400)] <anastasiac> jamon, pong
[12:08:17 EDT(-0400)] <jamon> hey anastasiac, looking at vhosts on tron, are you using transformable-sakai.atrc.utoronto.ca? i can move it to giga or archive it depending on what you like
[12:08:32 EDT(-0400)] <jamon> tron's disks look like they're failing and it is on my move list is why i ask now
[12:09:03 EDT(-0400)] <anastasiac> hm... it's not up and running, but it should be
[12:09:16 EDT(-0400)] <anastasiac> I would say we should keep it up
[12:09:27 EDT(-0400)] <jamon> yeah it isn't running since the disks are mounted read-only and thus tomcat can't start
[12:09:39 EDT(-0400)] <anastasiac> ah, ok
[12:09:45 EDT(-0400)] <jamon> checking with nakul about it now, but if i can move it to giga is that ok?
[12:09:50 EDT(-0400)] <anastasiac> yes, if you could move it, and resurrect it, that would be great
[12:10:06 EDT(-0400)] <jamon> cool, i'll let you know what do/find then
[12:10:11 EDT(-0400)] <anastasiac> thanks!
[12:12:11 EDT(-0400)] * laurel (n=laurel@dsl-207-112-77-116.tor.primus.ca) has joined #fluid-work
[13:12:13 EDT(-0400)] * Justin_o (n=Justin@142.150.154.171) has joined #fluid-work
[14:03:45 EDT(-0400)] <Justin_o> EricDalquist, athena: Hello
[14:03:53 EDT(-0400)] * athena waves
[14:04:19 EDT(-0400)] <Justin_o> I was looking at the issue about selecting text in the reorderer
[14:04:24 EDT(-0400)] <EricDalquist> hello
[14:04:37 EDT(-0400)] <Justin_o> http://www.ja-sig.org/issues/browse/UP-2442
[14:05:48 EDT(-0400)] <Justin_o> So it looks like a long time ago we had added some code because of an issue that selection was causing when an element was being dragged http://issues.fluidproject.org/browse/FLUID-143
[14:07:59 EDT(-0400)] <Justin_o> We have since refactored the reorderer and this no longer seems to be an issue, but the code to prevent text selection in IE was still present. I have removed this from our repository now, and the fix should be in Infusion 1.2 which will likely come out at the end of August
[14:09:19 EDT(-0400)] <EricDalquist> sounds good ... is there a patch we can offer up in the interem?
[14:09:36 EDT(-0400)] <Justin_o> hmm.. not at the moment, but that is a possibility
[14:10:13 EDT(-0400)] <colinclark> this is where athena can probably advise us
[14:10:21 EDT(-0400)] <colinclark> we can certainly make a patch... but of what sort?
[14:10:36 EDT(-0400)] <athena> hm
[14:10:42 EDT(-0400)] <colinclark> we can cut a new Infusion-All which users can drop in as a replacement
[14:10:46 EDT(-0400)] <athena> i think uportal is currently using 0.8
[14:11:00 EDT(-0400)] <athena> we'd actually need a patch against the 0.8 branch, most likely
[14:11:02 EDT(-0400)] <EricDalquist> and we only have the 3.1.0 and 3.1.1 releases out there with it
[14:11:13 EDT(-0400)] <colinclark> ok, i think we can do that
[14:11:25 EDT(-0400)] <athena> we use a custom build of the files
[14:11:49 EDT(-0400)] <athena> EricDalquist: i'm thinking maybe we could add a 0.8.1 version to the resource serving webapp or something?
[14:12:01 EDT(-0400)] <athena> so that we could provide the patch for 3.0.x and 3.1.x users?
[14:12:01 EDT(-0400)] <EricDalquist> that would be just fine
[14:12:04 EDT(-0400)] <EricDalquist> yup
[14:12:07 EDT(-0400)] <EricDalquist> and that is an easy patch
[14:12:10 EDT(-0400)] <athena> yeah
[14:12:27 EDT(-0400)] <athena> don't want to update the existing file since it's got such a long expiration date, but i think that'd work fine
[14:13:49 EDT(-0400)] <colinclark> athena: So, in other words, you want a 0.8.1 release that you can build, and then you'll create a uP 3.1.2 patch or whatever that links to the new file?
[14:14:03 EDT(-0400)] <colinclark> Or what works best for you? In short, we'll do whatever you need. Dumb bug, so we want to fix it.
[14:14:26 EDT(-0400)] <athena> yes, colinclark, i think that's right
[14:14:51 EDT(-0400)] <athena> even just a patch against the 0.8 branch would allow us to build a new file, i think
[14:15:04 EDT(-0400)] <colinclark> ok
[14:15:27 EDT(-0400)] <EricDalquist> yeah
[14:15:41 EDT(-0400)] <colinclark> so Justin_o, either way it sounds like the next step is to make a branch off the 0.8 tag and make the fix there
[14:16:00 EDT(-0400)] <colinclark> i don't think the reorderer changed much at all between 0.8 and 1.0
[14:16:12 EDT(-0400)] <colinclark> except in terms of style normalization
[14:16:49 EDT(-0400)] <athena> colinclark: that was sort of my impression too
[14:16:58 EDT(-0400)] <athena> i've been meaning to update the portal trunk to 1.1
[14:17:21 EDT(-0400)] <Justin_o> colinclark: i'll look into making an update to that now
[14:17:23 EDT(-0400)] <colinclark> 1.2 is coming at the end of August, in case that makes any difference
[14:17:32 EDT(-0400)] <athena> yeah, looking forward to it
[14:17:39 EDT(-0400)] <colinclark> Justin_o: So you can just call the new branch 0.8.x. Just copy from the tag into your new branch.
[14:19:14 EDT(-0400)] <colinclark> EricDalquist, athena: Thanks so much. This shouldn't take long. The fix is insanely easy, it's just the QA time.
[14:19:23 EDT(-0400)] <athena> well we appreciate you fixing it!
[14:19:45 EDT(-0400)] <EricDalquist> yeah, I think there will be a lot of happy people when that one gets knocked off
[14:19:46 EDT(-0400)] <EricDalquist> thanks
[14:20:24 EDT(-0400)] * athena wishes IE would just go die a quiet death
[14:20:40 EDT(-0400)] <colinclark> you know, there's a fair bit of talk about that again recently
[14:20:49 EDT(-0400)] <colinclark> a few prominent sites have decided to finally just drop it
[14:21:02 EDT(-0400)] <colinclark> i think in higher ed and, even more so in the cultural sector, it's probably too early
[14:21:32 EDT(-0400)] <athena> yeah
[14:21:36 EDT(-0400)] <colinclark> athena: I'll buy you beers if IE isn't dead by 2011, though.
[14:21:36 EDT(-0400)] <athena> more standardization, please
[14:21:46 EDT(-0400)] <athena> lol
[14:21:52 EDT(-0400)] <athena> we'd need to agree on a definition of "dead"
[14:22:06 EDT(-0400)] <colinclark> how about:
[14:22:15 EDT(-0400)] <colinclark> not actively supported by uPortal or Fluid
[14:22:32 EDT(-0400)] <athena> sounds good to me!
[14:22:43 EDT(-0400)] <athena> and if we're still supporting it in 2011, i'll buy you beer and we can cry into them
[14:22:48 EDT(-0400)] <colinclark> lol
[14:22:49 EDT(-0400)] <colinclark> deal
[14:22:57 EDT(-0400)] * colinclark better start saving for beers in 2011.
[14:23:19 EDT(-0400)] <athena> the thing that hurts most is the managed workstations / lab computers that aren't updated frequently
[14:23:28 EDT(-0400)] <athena> those are the ones still running IE6
[14:23:28 EDT(-0400)] <colinclark> yep
[14:23:41 EDT(-0400)] <colinclark> there was actually an article on ajaxian about that recently
[14:23:54 EDT(-0400)] <colinclark> in the end, the people who are still using IE6 are probably running something much newer at home
[14:24:00 EDT(-0400)] <athena> having once worked in a group that managed campus labs, the implied lack of security updates makes my skin crawl
[14:24:01 EDT(-0400)] <athena> yep
[14:24:04 EDT(-0400)] <colinclark> but they're stuck in a corporate or lab environment
[14:24:04 EDT(-0400)] <colinclark> yep
[14:24:25 EDT(-0400)] <athena> yeah
[14:24:41 EDT(-0400)] <athena> should be possible in this day and age to roll out OS updates
[14:24:43 EDT(-0400)] * athena sighs
[14:25:02 EDT(-0400)] <colinclark> these days, in the back of my mind, i've been thinking about how we can support less awesome cell phones
[14:25:09 EDT(-0400)] <colinclark> i mean, your 3GS is a slam dunk
[14:25:22 EDT(-0400)] <colinclark> but could we support, say, and old Sony Ericsson or something?
[14:25:40 EDT(-0400)] <athena> the work i did was based on some support designed for older blackberries
[14:25:46 EDT(-0400)] <colinclark> So just in time for getting rid of IE, we'll be supporting old weird proprietary cell browsers.
[14:25:47 EDT(-0400)] <athena> no javascript, etc.
[14:25:48 EDT(-0400)] <colinclark> yeah, exactly!
[14:25:55 EDT(-0400)] <athena> so we've actually already got that there
[14:26:00 EDT(-0400)] <colinclark> that's great
[14:26:10 EDT(-0400)] <colinclark> we'll just borrow your implementation
[14:26:26 EDT(-0400)] <athena> and uportal already in theory supports delivering different XSL sets for different user agents, as matched by regex
[14:26:32 EDT(-0400)] <colinclark> right
[14:27:05 EDT(-0400)] <colinclark> Justin_o: Did you notice that in Q4 2009, Yahoo is going to add a graded mobile browser support matrix?
[14:27:14 EDT(-0400)] <colinclark> Just in time for us to start shipping Engage
[14:27:38 EDT(-0400)] <athena> oh, interesting
[14:27:47 EDT(-0400)] <athena> so colinclark the thing for us that's less clear is how to deal w/ the portlets
[14:27:56 EDT(-0400)] <colinclark> ah, yes
[14:28:00 EDT(-0400)] <athena> because some of those may or may not work on older mobile devices
[14:28:27 EDT(-0400)] <colinclark> i guess, in some ideal world, you'd have some sense of the capabilities of each portlet
[14:28:30 EDT(-0400)] <athena> yeah
[14:28:34 EDT(-0400)] <colinclark> and just not show the ones that are incompatible
[14:28:37 EDT(-0400)] <colinclark> but it'll never happen
[14:29:00 EDT(-0400)] <athena> well, one possibility would be to use different layouts for mobile themes
[14:29:13 EDT(-0400)] <colinclark> the thing we're playing around with, in concept at least, is being able to adapt markup to make it more suitable for a mobile device after the fact
[14:29:19 EDT(-0400)] <colinclark> still, js support and the like would be a problem
[14:29:26 EDT(-0400)] <colinclark> athena: tell me more about that
[14:29:56 EDT(-0400)] <athena> which? the different layouts?
[14:30:33 EDT(-0400)] <colinclark> yeah
[14:31:10 EDT(-0400)] <athena> so basically uportal has "layouts", which store what channels, tabs, etc. you have in your layout
[14:31:28 EDT(-0400)] <athena> they're store in database rows and represented in the portal in XML format
[14:31:45 EDT(-0400)] <colinclark> yep
[14:31:53 EDT(-0400)] <athena> the portal transforms the XML once through a "structure" XSLT
[14:31:59 EDT(-0400)] <athena> then once through a "theme" XSLT
[14:32:02 EDT(-0400)] <colinclark> right
[14:32:27 EDT(-0400)] <athena> so uportal also has "profiles" that tie together a layout id, structure id, and theme id for a given user id
[14:32:50 EDT(-0400)] <athena> so you might have one that's called "mobile" that says to use a particular structure and theme and layout number "2"
[14:33:03 EDT(-0400)] <athena> and a "normal" one that uses a different structure and/or theme and layout number "1"
[14:33:09 EDT(-0400)] <athena> or they might actually share the same layout
[14:33:36 EDT(-0400)] <athena> and then there's both system-wide and user-specific ways of choosing profiles based on a browser user agent
[14:34:00 EDT(-0400)] <colinclark> would that address the problem of the portlets, though?
[14:34:03 EDT(-0400)] <athena> unicon's cooperative dev program is currently working on fixing the auto-creation of profiles based on a template user, which seems to have been accidentally broken at some point
[14:34:17 EDT(-0400)] <athena> the multiple layout stuff probably wouldnt' really work right now, but it's fixable were it important
[14:34:21 EDT(-0400)] <athena> not really
[14:34:54 EDT(-0400)] <athena> maybe you could have different layouts, in which case you could not include more heavy-duty portlets in the mobile layout
[14:35:09 EDT(-0400)] <colinclark> right
[14:35:22 EDT(-0400)] <athena> it might be possible to leverage the permissions model or something to suppress portlets in the mobile version if you were sharing layouts - i'm not sure
[14:35:34 EDT(-0400)] <colinclark> ah, interesting
[14:35:50 EDT(-0400)] <colinclark> i guess, in the end, it speaks to the need to design portlets that are nicely optimized for mobile
[14:36:37 EDT(-0400)] <athena> yes, probably
[14:36:57 EDT(-0400)] <athena> of course, one of the big problems with portal development is that often we can't control the content
[14:37:11 EDT(-0400)] <athena> which is why i'd probably be worried about allowing fluid js to re-write markup to make it more mobile-happy
[14:37:19 EDT(-0400)] <athena> we have a lot of poorly-marked up content
[14:37:26 EDT(-0400)] <athena> legacy portlet/channels
[14:37:29 EDT(-0400)] <colinclark> yeah, it's not a complete solution
[14:37:34 EDT(-0400)] <athena> 3rd party / closed source integration portlets
[14:37:41 EDT(-0400)] <colinclark> in fact, it couldn't possibly work without the cooperation of the original author
[14:37:44 EDT(-0400)] <athena> and worst of all, web proxy from poorly-coded sites
[14:37:48 EDT(-0400)] <athena> yeah
[14:37:55 EDT(-0400)] <colinclark> our goal is more to lower the cost of migrating existing content to mobile
[14:38:01 EDT(-0400)] <athena> yeah
[14:38:07 EDT(-0400)] <athena> i'd agree we have some unique needs
[14:38:13 EDT(-0400)] <colinclark> but for some portlet that isn't quite there, this approach wouldn't cut it at all
[14:38:18 EDT(-0400)] <athena> yeah
[14:38:23 EDT(-0400)] <colinclark> i don't think you have terribly unique needs... crappy markup is everywhere
[14:39:12 EDT(-0400)] <athena> true
[14:39:26 EDT(-0400)] * athena notes that timecave is now set to send out a beer reminder email on Jan 1, 2011
[14:40:17 EDT(-0400)] <athena> i still want to talk about the possibilities of using FSS for portlet markup someday too
[14:41:56 EDT(-0400)] <colinclark> that'd be cool
[14:43:44 EDT(-0400)] <athena> yeah
[14:43:52 EDT(-0400)] <athena> i know gary had some concerns about it
[14:44:13 EDT(-0400)] <athena> but it seems like there has to be a way to make everything work happily without us coming up with our own css classnames
[14:47:14 EDT(-0400)] <colinclark> what were gary's concerns?
[14:48:47 EDT(-0400)] <athena> i'm trying to remember - i didn't completely understand them
[14:48:51 EDT(-0400)] <athena> CSS not really being my thing
[14:49:13 EDT(-0400)] <athena> however, i think at least part of it was that we were using the widgety-y styles to describe the chrome around the portlet
[14:49:23 EDT(-0400)] <athena> which didn't really leave us with anything to use for the innards of the portlet
[14:50:32 EDT(-0400)] <athena> here's gary's email with his proposal for uportal: http://www.mail-archive.com/uportal-dev@lists.ja-sig.org/msg01854.html
[14:50:57 EDT(-0400)] <athena> i think i've finally conceded that jsr-168 styles don't get us far enough, but it'd be awesome if we could use styles that weren't just uportal-specific
[14:56:14 EDT(-0400)] <colinclark> yeah
[14:56:18 EDT(-0400)] <colinclark> the jsr-168 styles are so sad
[14:56:25 EDT(-0400)] <colinclark> ambiguous as hell
[14:56:45 EDT(-0400)] <athena> agreed
[14:56:47 EDT(-0400)] <athena> it's pretty painful
[15:20:40 EDT(-0400)] <Justin_o> colinclark and others: do you think i should be changing the version numbers within the code to something like 0_8_1 or will it be safe to leave it at 0_8
[15:21:22 EDT(-0400)] <colinclark> Justin_o: funny, I was just wondering that myself.
[15:22:12 EDT(-0400)] <colinclark> michelled: Do you have any thoughts on that?
[15:22:31 EDT(-0400)] <colinclark> athena: Do you use our versioning feature in uPortal at all, or do you just bind to the "fluid" namespace?
[15:22:38 EDT(-0400)] <michelled> I think it's not worth the work of changing the version number
[15:22:46 EDT(-0400)] <athena> you know, i don't think we've started using it yet
[15:22:50 EDT(-0400)] <athena> though we should
[15:22:52 EDT(-0400)] <michelled> the APIs all stay the same so there's no danger in the code blowing up
[15:22:57 EDT(-0400)] <colinclark> michelled: Let me be devil's advocate for a moment, though...
[15:23:00 EDT(-0400)] <athena> it's a really nice feature
[15:23:05 EDT(-0400)] <athena> i really wish jquery did the same
[15:23:09 EDT(-0400)] <athena> we'd be so much better off
[15:23:10 EDT(-0400)] <colinclark> What good is a version number if it's not used.
[15:23:31 EDT(-0400)] <athena> well, part of the problem now is that we're having to explicitly clear the namespace because of jquery
[15:23:42 EDT(-0400)] <colinclark> right
[15:24:28 EDT(-0400)] <EricDalquist> I was actually just thinking more about all the JavaScript loading crazyness
[15:24:43 EDT(-0400)] <EricDalquist> and wishing there was a nice way to only load what is needed on the page
[15:28:45 EDT(-0400)] <EricDalquist> with jQuery & Fluid loading plugins and such is generally additive right?
[15:29:04 EDT(-0400)] <EricDalquist> like a plugin doesn't redefine existing APIs
[15:29:32 EDT(-0400)] <colinclark> EricDalquist: Generally, yes. There's nothing in the language that prevents runtime modification of an API, though
[15:29:40 EDT(-0400)] <EricDalquist> right
[15:30:14 EDT(-0400)] <EricDalquist> I've just been playing with JS more lately and in a portal environment I'm really wishing for some sort of smart JS loading framework
[15:30:23 EDT(-0400)] <EricDalquist> just trying to think of ways it could be done
[15:31:12 EDT(-0400)] <michelled> colinclark: I guess I'm thinking that there probably aren't people who require a specific point release over another. we'd still continue to change the version number between major releases. meaning 1.2 to 1.3.
[15:31:14 EDT(-0400)] <michelled> I suppose that we could in the future have a large enough difference between two minor releases that we'd want to be able to call them by number and I suppose we are setting the standard for minor releases with 0.8.1.
[15:31:39 EDT(-0400)] * michelled knows she just argued both sides
[15:31:50 EDT(-0400)] <colinclark> lol
[15:33:24 EDT(-0400)] <colinclark> EricDalquist: I have been puzzling over that for awhile now... it's a really tough problem.
[15:33:49 EDT(-0400)] <colinclark> michelled: I'm slightly distracted with proposal writing, having trouble thinking through this clearly...
[15:34:22 EDT(-0400)] <colinclark> I mean, if we were to cut a new version, it's a new version. That said, someone who was binding to a specific version would be required to update their code.
[15:34:33 EDT(-0400)] <colinclark> But I guess that's the point of binding to a specific version.
[15:34:40 EDT(-0400)] <EricDalquist> and then of course if you create a loading framework to do this sort of thing you're stuck trying to deal with multiple includes of the loading framework
[15:34:54 EDT(-0400)] <colinclark> And it's a natural weakness of our versioning strategy, in that it doesn't have any way of distinguishing major vs. minor revisions.
[15:34:57 EDT(-0400)] <EricDalquist> what does Andrew always say ... turtles all the way down ...
[15:35:03 EDT(-0400)] <colinclark> lol
[15:35:08 EDT(-0400)] <colinclark> I like that expression a lot.
[15:35:43 EDT(-0400)] <colinclark> EricDalquist: The closest example to something like this I've seen in the wild is Dojo's, and it ends up being more trouble than it's worth most of the time.
[15:35:52 EDT(-0400)] <EricDalquist> yeah
[15:35:58 EDT(-0400)] <EricDalquist> I think everytime this comes up
[15:36:05 EDT(-0400)] <EricDalquist> and we start digging into how it would actually work
[15:36:20 EDT(-0400)] <EricDalquist> there are so many caveats that it doesn't really matter
[15:36:41 EDT(-0400)] <EricDalquist> and from what I've been browsers do seem to deal fairly well with having like 3 versions of jQuery all loaded on one page
[15:38:27 EDT(-0400)] <EricDalquist> though from a coding point of view it sure seems terrible
[15:38:36 EDT(-0400)] * laurel (n=laurel@dsl-207-112-77-116.tor.primus.ca) has joined #fluid-work
[15:38:50 EDT(-0400)] <colinclark>
[15:38:57 EDT(-0400)] * Justin_o (n=Justin@142.150.154.171) has left #fluid-work
[15:43:02 EDT(-0400)] * athena attempted to get sbattaglia to include more turtles in his slides. lots more turtles
[15:43:19 EDT(-0400)] <athena> yeah EricDalquist, it bothers me too
[15:43:30 EDT(-0400)] <athena> and i'm glad we have something that at least works now, but i agree it's not ideal
[15:43:47 EDT(-0400)] <athena> it worries me that i don't think jsr-286 is going to solve our problems there
[15:44:00 EDT(-0400)] <EricDalquist> it won;t
[15:44:05 EDT(-0400)] <athena> which is sad
[15:44:18 EDT(-0400)] <EricDalquist> all it will do is let us be good and put our script and link tags in the header
[15:44:30 EDT(-0400)] <EricDalquist> what we need is something like google jsapi on crack
[15:44:36 EDT(-0400)] <EricDalquist> they have nice loading semantics
[15:44:39 EDT(-0400)] <athena> yeah
[15:44:55 EDT(-0400)] <EricDalquist> but its this multiply inclusive issue that's hard
[15:46:16 EDT(-0400)] <EricDalquist> like it would be great if I could say: "I want jQuery 1.3.X loaded into the global variable myPortlet.jQuery
[15:46:25 EDT(-0400)] <EricDalquist> and the framework would see if something is already loaded
[15:46:35 EDT(-0400)] <EricDalquist> if so just add another pointer
[15:46:42 EDT(-0400)] <EricDalquist> if not load up the most recent version
[16:00:38 EDT(-0400)] <athena> the part i worry even more about is combinations of plugins
[16:00:53 EDT(-0400)] <athena> it's difficult to handle one portlet wanting jquery 1.3.2 and jquery ui 1.7.2
[16:01:03 EDT(-0400)] <athena> and another insisting that it really needs 1.3.2 and 1.7.1
[16:01:28 EDT(-0400)] <athena> i don't think we can achieve that without loading up both jquery and jquery ui twice
[16:02:42 EDT(-0400)] <EricDalquist> yeah
[16:02:58 EDT(-0400)] <EricDalquist> I think we talked about some options before
[16:03:10 EDT(-0400)] <EricDalquist> where a portlet would have to call something like:
[16:03:18 EDT(-0400)] <EricDalquist> jsapi.load({'jquery','
[16:03:20 EDT(-0400)] <EricDalquist> oops
[16:04:09 EDT(-0400)]

[16:04:33 EDT(-0400)] <EricDalquist> and the loader API would have to try and find something that works or do a load specifically for the requester
[16:06:06 EDT(-0400)] <athena> yeah
[16:06:09 EDT(-0400)] <athena> we did
[16:06:20 EDT(-0400)] * laurel (n=laurel@dsl-207-112-77-116.tor.primus.ca) has left #fluid-work
[16:06:25 EDT(-0400)] <athena> i think we sort of eventually decided it was more confusion than it was worth
[16:06:35 EDT(-0400)] <athena> especially with the requirement of adding that onloadcallback
[16:17:21 EDT(-0400)] <EricDalquist> yeah
[16:17:29 EDT(-0400)] <EricDalquist> and I dont' think that would have worked either'
[16:17:47 EDT(-0400)] <EricDalquist> I think we needed something like jQueries' noConflict() call
[16:18:04 EDT(-0400)] <EricDalquist> to allow for other <script> tags between the loader and the clearing of global
[16:52:49 EDT(-0400)] * justin_o (n=jmo@CPE001b63f2cc0e-CM0011aec4b062.cpe.net.cable.rogers.com) has joined #fluid-work
[17:18:31 EDT(-0400)] * anastasiac (n=team@142.150.154.189) has left #fluid-work
[18:07:33 EDT(-0400)] * heidi__ (n=thesumme@bas5-oshawa95-1176478111.dsl.bell.ca) has joined #fluid-work
[23:15:47 EDT(-0400)] * yura (n=yura@bas3-toronto06-1177890603.dsl.bell.ca) has joined #fluid-work