fluid-work IRC Logs-2009-08-03

[00:53:19 EDT(-0400)] * yura (n=yura@bas3-toronto06-1177890603.dsl.bell.ca) has joined #fluid-work
[02:29:15 EDT(-0400)] * athena (n=athena@75.58.122.144) has joined #fluid-work
[08:41:40 EDT(-0400)] * athena (n=athena@adsl-75-58-122-144.dsl.wlfrct.sbcglobal.net) has joined #fluid-work
[09:23:23 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[09:45:15 EDT(-0400)] * jamon (i=jamon@mantis.openject.com) has joined #fluid-work
[09:52:00 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[10:32:59 EDT(-0400)] * Bosmon (n=Bosmon@78-105-207-102.zone3.bethere.co.uk) has joined #fluid-work
[10:33:11 EDT(-0400)] <Bosmon> Hey, athena, EricDalquist - you there?
[10:33:21 EDT(-0400)] <EricDalquist> hey Bosmon
[10:33:54 EDT(-0400)] <Bosmon> Michelle relayed to me your chat from last week about IoC/demand loading... I sent a few comments back to her just before I dashed off for the weekend that I wonder whether they got back to you
[10:33:58 EDT(-0400)] <Bosmon> http://www.ja-sig.org/wiki/display/UPC/uPortal+IRC+Logs-2009-07-29
[10:34:04 EDT(-0400)] <Bosmon> Specifically about this conversation...
[10:34:15 EDT(-0400)] <athena> hey there
[10:34:57 EDT(-0400)] <EricDalquist> ah yeah
[10:35:15 EDT(-0400)] <EricDalquist> I need to read your wiki page a few more times before it will sink in
[10:35:37 EDT(-0400)] <EricDalquist> the area I'm trying to figure out more 'best practices' about is JavaScript loading in a portal environment
[10:35:53 EDT(-0400)] <EricDalquist> where the end goal would be to reduce the number of script loads for the page
[10:36:13 EDT(-0400)] <EricDalquist> and have it work with out too much coordination from the portal deployer
[10:36:19 EDT(-0400)] <Bosmon> Yes
[10:36:28 EDT(-0400)] <EricDalquist> so I could have the portal using jQuery 1.3 and Fluid 1.0
[10:36:37 EDT(-0400)] <EricDalquist> and several portlets using other versions of the same thing
[10:36:37 EDT(-0400)] <Bosmon> The IoC we are planning for the next release doesn't address this issue specifically - but it is one we have been aware of for a long time
[10:36:43 EDT(-0400)] <EricDalquist> yeah
[10:36:55 EDT(-0400)] <EricDalquist> and fluid is good about being careful with namespaces
[10:36:58 EDT(-0400)] <athena> yeah
[10:37:05 EDT(-0400)] <athena> if jquery just did the same thing we'd be in better shape
[10:37:09 EDT(-0400)] <Bosmon> We were planning to think about a standardised solution in the 0.6-0.8 timeframe called the "Fluid Loader" but haven't managed to yet get to it
[10:37:18 EDT(-0400)] <Bosmon> What you said about the two methods of script loading we can certainly confirm
[10:37:31 EDT(-0400)] <Bosmon> The jQuery based "ajax" method, based on "eval" is quite deficient, from various points of view
[10:37:40 EDT(-0400)] <EricDalquist> have you looked at the YUI get utility?
[10:37:49 EDT(-0400)] <EricDalquist> it is a cross-browser <script> approach
[10:37:52 EDT(-0400)] <Bosmon> So, the Sakai guys have been doing this for a while, using the "script" injection technique you mention, and reports it works quite well
[10:37:56 EDT(-0400)] <EricDalquist> with an onload callback
[10:38:06 EDT(-0400)] <EricDalquist> there are some browser quirks
[10:38:09 EDT(-0400)] <Bosmon> I had asked Nico to package their (very short) code as a jQuery plugin, which I believe he has done
[10:38:13 EDT(-0400)] <athena> my concern with using that style of loading is that we'd have to chain the onloads
[10:38:14 EDT(-0400)] <EricDalquist> but looking at their code it isn't too complex to get working
[10:38:19 EDT(-0400)] <EricDalquist> athena: yes
[10:38:26 EDT(-0400)] <EricDalquist> you have a dependency tree type situation
[10:38:32 EDT(-0400)] <athena> because we'd probably have to wait for jquery to load, then jquery ui, then fluid, then custom stuff . . .
[10:38:38 EDT(-0400)] <EricDalquist> yup
[10:38:48 EDT(-0400)] <EricDalquist> http://code.google.com/p/jingo/
[10:38:51 EDT(-0400)] <Bosmon> So it might be worth standardising on the use of that in the meantime - the main thing holding us up doing this in Fluid is thinking about "SecurableModules"
[10:38:54 EDT(-0400)] <EricDalquist> that is what that library does
[10:38:55 EDT(-0400)] <athena> and since that prevents the browser for downloading anything in parallel, i'm worried that could get slow
[10:39:08 EDT(-0400)] <EricDalquist> but it requires all the scripts loaded have a special jingo wrapper
[10:39:19 EDT(-0400)] <Bosmon> https://wiki.mozilla.org/ServerJS/Modules/SecurableModules
[10:39:20 EDT(-0400)] <EricDalquist> ah, I hadn't thought about that athena
[10:39:33 EDT(-0400)] <athena> yeah, that was actually the reason why i gave up on that approach
[10:39:34 EDT(-0400)] <Bosmon> It's unclear to us whether this is something we want to support, but it does represent a standardised solution to the problem
[10:39:50 EDT(-0400)] <Bosmon> But I don't think the implications of adopting this model are yet clear to us
[10:39:54 EDT(-0400)] <athena> that was how i'd started coding the resource server stuff originally, but i was really worried about performance
[10:40:10 EDT(-0400)] <Bosmon> Well, the point about head "script" injection is that it does allow the browser to load things in parallel
[10:40:25 EDT(-0400)] <athena> ok
[10:40:47 EDT(-0400)] <athena> so we could inject several scripts that way and they'd init properly, and just wait and make sure all of them are loaded?
[10:40:55 EDT(-0400)] <athena> here's my other major concern
[10:41:09 EDT(-0400)] <Bosmon> SecurableModules is a very different approach to managing the global namespace than the one we have - but for us we could adopt this with just a change to our "file boilerplate"
[10:41:32 EDT(-0400)] <Bosmon> On the other hand, it is not actually clear that SecurableModules offers us very much, at least in Fluid, since our global namespace discipline is already quite good enough
[10:41:40 EDT(-0400)] <athena> i worry that we'll still have to download a bunch of scripts multiple times anyway
[10:41:59 EDT(-0400)] <athena> because one portlet will want jquery 1.3.2 + jquery ui 1.7.1 + fluid 1.1
[10:42:10 EDT(-0400)] <athena> and one will want jquery 1.3.2 + jquery ui 1.7.2 + fluid 1.1
[10:42:16 EDT(-0400)] <EricDalquist> right
[10:42:26 EDT(-0400)] <EricDalquist> so the meta-loader would have to have some sort of rules system about that
[10:42:26 EDT(-0400)] <athena> so we won't really have gained that much
[10:42:33 EDT(-0400)] <Bosmon> that is one type of issue that an SM-like solution would solve
[10:42:48 EDT(-0400)] <Bosmon> It is a shame that we went away in Fluid from embedding library version numbers in filenames
[10:42:51 EDT(-0400)] <EricDalquist> is SM something that would work cross-browser right now?
[10:43:03 EDT(-0400)] <EricDalquist> we added that back in for uPortal
[10:43:07 EDT(-0400)] <Bosmon> EricDalquist: It "is", in theory, but it is really a spec, rather than a particular implementation
[10:43:16 EDT(-0400)] <EricDalquist> ok
[10:43:24 EDT(-0400)] <Bosmon> So you really have to talk about a specific impl to talk about portability
[10:43:45 EDT(-0400)] <Bosmon> I think one thing Nico's plugin does is normalise on file paths, and I'm sure we could tweak it to normalise by file names too....
[10:43:57 EDT(-0400)] <Bosmon> But it is something we plan to support explicitly in Fluid once we can come up with a good model
[10:44:11 EDT(-0400)] <Bosmon> We have all the infrastructure there within our module dependency declaration .json files
[10:44:49 EDT(-0400)] <Bosmon> I am talking to Nico now about his plugin....
[15:11:18 EDT(-0400)] * yura (n=yura@bas3-toronto06-1177890603.dsl.bell.ca) has joined #fluid-work