fluid-work IRC Logs-2008-07-21

[08:12:57 EDT(-0400)] * Justin_o (n=Justin@142.150.154.235) has joined #fluid-work
[08:13:17 EDT(-0400)] * Justin_o (n=Justin@142.150.154.235) has left #fluid-work
[08:52:32 EDT(-0400)] * anastasiac (n=stasia@142.150.154.160) has joined #fluid-work
[08:57:11 EDT(-0400)] * Jacob1 (n=Fluid@142.150.154.106) has joined #fluid-work
[08:58:13 EDT(-0400)] * Jacob1 (n=Fluid@142.150.154.106) has left #fluid-work
[09:06:10 EDT(-0400)] * Jacob1 (n=Fluid@142.150.154.106) has joined #fluid-work
[09:29:22 EDT(-0400)] * jessm (n=Jess@rrcs-70-63-141-143.midsouth.biz.rr.com) has joined #fluid-work
[09:43:47 EDT(-0400)] * phiggins (n=dante@12.157.240.85) has joined #fluid-work
[09:44:03 EDT(-0400)] * theclown (n=theclown@142.150.154.101) has joined #fluid-work
[09:58:56 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[10:16:32 EDT(-0400)] * anastasiac (n=team@142.150.154.160) has joined #fluid-work
[10:40:33 EDT(-0400)] <Bosmon> Ping
[10:41:47 EDT(-0400)] <jessm> Bosmon: pong
[10:53:37 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[10:55:00 EDT(-0400)] <Bosmon> That is one very agile CAT
[10:55:58 EDT(-0400)] <theclown> what CAT? where CAT?
[11:14:32 EDT(-0400)] * phiggins (n=dante@conference/oscon/x-f8ccfbdb5ee8a70b) has joined #fluid-work
[11:20:37 EDT(-0400)] <Bosmon> Sakai and Fluid are the first representatives of a revolutionary new style in development management
[11:20:58 EDT(-0400)] <Bosmon> Whereas once it was the case that programmers were herded like cats, they are now in the new model herded by cats
[11:31:45 EDT(-0400)] <theclown> colinclark, in case you haven't found it, the dijitclick basic handling is in .../dijit/_Widget.js. Look for the connect() method.
[11:32:00 EDT(-0400)] <colinclark> theclown: Cool thanks!
[11:32:08 EDT(-0400)] <theclown> colinclark: no problem.
[12:02:00 EDT(-0400)] <Bosmon> Global "external contract for components" JIRA wrt. model and rendering: http://issues.fluidproject.org/browse/FLUID-958
[12:02:29 EDT(-0400)] <anastasiac> Bosmon, I don't know if you heard what Colin was in the middle of saying when you joined stand-up
[12:02:31 EDT(-0400)] <Bosmon> Overal "size change on state change" JIRA: http://issues.fluidproject.org/browse/FLUID-957
[12:02:37 EDT(-0400)] <Bosmon> Yes, sort of half of it
[12:02:45 EDT(-0400)] <anastasiac> regarding container id/selectors
[12:02:49 EDT(-0400)] <Bosmon> He seemed to be saying that he no longer considered the "string as id" idiom was a good one
[12:02:51 EDT(-0400)] <Bosmon> Is that right?
[12:02:53 EDT(-0400)] <anastasiac> we're going to go with selectors, and not ids
[12:02:59 EDT(-0400)] <Bosmon> ok, cool
[12:03:07 EDT(-0400)] <anastasiac> so fluid.container() needs to be adjusted to handle that
[12:03:18 EDT(-0400)] <anastasiac> and then components that use it need to adjust, and so on, and so on
[12:05:56 EDT(-0400)] <anastasiac> thanks for the links to those JIRAs, Bosmon
[12:06:54 EDT(-0400)] <Bosmon> What I was saying to Colin just before standup is at the bare minimum, I guess we would expect each "participating component" to be able to respond to a call such as render(model), which would refresh its instantiation in the DOM with respect to a new "model object"
[12:07:15 EDT(-0400)] <Bosmon> This would of course also have to interact with any "fossil bolus" that could be found as a result of rendering it
[12:07:26 EDT(-0400)] <Bosmon> And that we would want something resembling "reasonable model semantics"
[12:07:58 EDT(-0400)] <Bosmon> (16:01:10) Antranig: I am imagining that we will "enforce" that each component supply an "instance", which will respond to a call of the form "render(model)"
[12:07:59 EDT(-0400)] <Bosmon> (16:01:22) Antranig: Where model is some arbitrary, but "value-oriented" block of JSON
[12:08:16 EDT(-0400)] <Bosmon> (16:01:24) Clark Kent: hmm
[12:08:16 EDT(-0400)] <Bosmon> (16:01:27) Clark Kent: interesting
[12:08:16 EDT(-0400)] <Bosmon> (16:01:38) Clark Kent: value oriented in what way?
[12:08:16 EDT(-0400)] <Bosmon> (16:01:56) Antranig: Well, that it will respond to semantics of the sort operated by the likes of jQuery.extend and RSF.deepEquiv
[12:08:16 EDT(-0400)] <Bosmon> (16:02:11) Antranig: That is, it contains no weird dangling closures or function pointers
[12:08:17 EDT(-0400)] <Bosmon> (16:03:00) Clark Kent: Meaning it would have no behaviour attached to it, just values?
[12:08:19 EDT(-0400)] <Bosmon> (16:03:02) Antranig: Yes
[12:08:21 EDT(-0400)] <Bosmon> (16:03:18) Antranig: No members of type "function"
[12:08:23 EDT(-0400)] <Bosmon> (16:03:23) Clark Kent: Why this limitation?
[12:08:25 EDT(-0400)] <Bosmon> (16:03:40) Antranig: So that it can be sensibly manipulated, tested for equivalence, serialised, etc.
[12:08:48 EDT(-0400)] <Bosmon> (16:04:46) Antranig: I am "hoping" this kind of approach might also build bridges towards whatever weird kind of stuff the "offline working" crowd might want to operate
[12:09:47 EDT(-0400)] <Bosmon> (16:04:00) Clark Kent: Hmm...
[12:09:48 EDT(-0400)] <Bosmon> (16:04:04) Antranig: I mean, a "global undo manager" could hardly expect to sensibly "undo" the effect where one function pointer were exchanged for another
[12:09:48 EDT(-0400)] <Bosmon> (16:04:14) Antranig: If it couldn't actually verify or "recover" either of the values
[12:09:48 EDT(-0400)] <Bosmon> (16:04:14) Clark Kent: That's certainly true.
[12:21:59 EDT(-0400)] * phiggins (n=dante@12.157.240.85) has joined #fluid-work
[13:01:24 EDT(-0400)] * Justin_o (n=Justin@142.150.154.235) has joined #fluid-work
[13:02:51 EDT(-0400)] * jhung (n=Jon@142.150.154.211) has joined #fluid-work
[13:03:09 EDT(-0400)] <jhung> So... I just had a brick thrown at me.
[13:04:02 EDT(-0400)] <anastasiac> jhung, Bosmon has been having some trouble saving and submitting his blog post
[13:04:56 EDT(-0400)] <Bosmon> It's the Fluid Brick!
[13:05:05 EDT(-0400)] <Bosmon> Yes, it seems all blog actions are broken
[13:05:09 EDT(-0400)] <Bosmon> Except, oddly, the autosave
[13:05:49 EDT(-0400)] <Bosmon> So, using purely that action, I have managed to get a posting, (id = 20) pretty much up to the point of being ready to be submitted....
[13:05:51 EDT(-0400)] <jhung> blog be buggered.
[13:06:14 EDT(-0400)] <jhung> I've seen a similar problem before and I think it's due time we did an update of the software.
[13:06:17 EDT(-0400)] <Bosmon> Colin was wondering whether this has happened through some kind of "PHP injection attack"?
[13:06:26 EDT(-0400)] <jhung> We're horribly out of date and we're losing our fight against spammers.
[13:06:46 EDT(-0400)] <jhung> Possibly.
[13:07:04 EDT(-0400)] <jhung> We need to update. I'll try to get this done today.
[13:10:44 EDT(-0400)] <Bosmon> Yay BLOG
[13:29:36 EDT(-0400)] * jessm (n=Jess@rrcs-70-63-141-143.midsouth.biz.rr.com) has joined #fluid-work
[14:27:33 EDT(-0400)] * phiggins (n=dante@12.157.240.85) has joined #fluid-work
[14:42:27 EDT(-0400)] <jhung> Bosmon, can you dump your browser cookies and log into the Blog again?
[14:42:42 EDT(-0400)] <jhung> I've done the upgrade. Let me know if there's anything weird.
[15:01:18 EDT(-0400)] <Bosmon> Cool, will try shortly
[15:01:41 EDT(-0400)] <Bosmon> So, Colin and I are discussing strategies for "helpfully" dividing single large units (such as InlineEdit or Uploader) into smaller logical units
[15:01:58 EDT(-0400)] <Bosmon> Which, at "first pass" each of these smaller units would be blessed with their own "that"
[15:02:12 EDT(-0400)] <colinclark> jhung: Awesome, the blog is spam-free again!
[15:02:15 EDT(-0400)] <Bosmon> The trouble with trying to do this "naively" is that it simply won't be readily visually obvious where these boundaries are
[15:02:37 EDT(-0400)] <colinclark> A lot of separate thats...
[15:02:45 EDT(-0400)] <Bosmon> And it will be all too easy for people coming upon the file to "not know again" what it is that "that" is referring to, or write non-contextual functions, or mix up things belonging to one unit with those of another
[15:03:06 EDT(-0400)] <Bosmon> So what I was thinking was that, following on from the tangible benefits of "Colinism", we should try to do something similar for "sub-thats"
[15:03:38 EDT(-0400)] <colinclark> A convention for naming...
[15:03:40 EDT(-0400)] <Bosmon> That is, to visibly "brand" each method as belonging to a particular "type" of that
[15:03:54 EDT(-0400)] <Bosmon> Although we had a separate discussion about what a terrible name for these kinds of unit a "type" is
[15:03:59 EDT(-0400)] <Bosmon> Anyway, there are two main options
[15:04:22 EDT(-0400)] <Bosmon> Say we are looking at a unit of the Uploader called the fileQueue -
[15:04:23 EDT(-0400)] * ecochran (n=ecochran@dhcp-169-229-212-100.LIPS.Berkeley.EDU) has joined #fluid-work
[15:05:10 EDT(-0400)] <Bosmon> We can either write for a fileQueue member that was simply named perhaps "update", we would write rather than simply update(that), maybe either
[15:05:21 EDT(-0400)] <Bosmon> fileQueue_update(that), or update(fileQueue_that)
[15:05:38 EDT(-0400)] <colinclark> I loathe underscores.
[15:05:40 EDT(-0400)] <Bosmon> Perhaps a problem with the latter is that some of the methods "of" the fileQueue might not actually be "that-ism" but still arg-ist
[15:05:52 EDT(-0400)] <Bosmon> So this actually suggests the former would be a more reliable choice
[15:05:57 EDT(-0400)] <Bosmon> Perhaps you prefer dollar signs!!!
[15:06:02 EDT(-0400)] <Bosmon> You crypto VMS-ite!
[15:06:09 EDT(-0400)] <colinclark> lol
[15:06:14 EDT(-0400)] <Bosmon> Do you really think fileQueue$update(that) actually looks better?
[15:06:19 EDT(-0400)] <colinclark> NO!
[15:06:31 EDT(-0400)] <colinclark> Delimiters!
[15:08:12 EDT(-0400)] <Bosmon> This is in advance of a much longer-term plan to "make it easier to write in smaller files"
[15:08:31 EDT(-0400)] <colinclark> In this case, wouldn't it be just as easy to read if we used a convention like this:
[15:08:53 EDT(-0400)] <colinclark> update(fileQueue)
[15:09:15 EDT(-0400)] <colinclark> And limit our reference to "that" within the creator function itself?
[15:09:19 EDT(-0400)] <Bosmon> My idea is to supply an "auto-build" system that will avoid our current ridiculous necessity to, when developing in the filesystem, write out billions of really silly physical paths like the following:
[15:09:27 EDT(-0400)] <Bosmon> <script type="text/javascript" src="../../../fluid-components/js/fluid/InlineEdit.js"></script>
[15:09:57 EDT(-0400)] <Bosmon> colinclark: The problem with that is the thing I observed up there - how do we distinguish functions that are still part of the same "logical unit", but are not actually sharing the full "that" object?
[15:10:12 EDT(-0400)] <Bosmon> That is, we ALSO want to be able to identify "arg-ist" members, that are still part of the same "grouping"
[15:10:24 EDT(-0400)] <Bosmon> At least, where they can be considered part of the grouping
[15:10:39 EDT(-0400)] <Bosmon> Perhaps a few "arg-ist" elements will actually straddle the boundaries between subunits
[15:10:55 EDT(-0400)] <Bosmon> But many of them will have quite clearly focused areas of responsibility, even if they are not handed a full "that"
[15:11:13 EDT(-0400)] <Bosmon> And should we enable "small files working" might well be put in the same file with the full that-ist functions
[15:12:07 EDT(-0400)] <Bosmon> Anyway, the "long term" idea is to build a kind of "fluid loader", relying on the observation we have found that injecting <script> material dynamically into <head>, and <style> material into <body> is actually reliable and cross-browser
[15:12:33 EDT(-0400)] <Bosmon> Since this actually works, it has always been a mystery that the dojo implementation of dojo.require has been so malign....
[15:14:28 EDT(-0400)] <Bosmon> But in the "user-facing" sense fluid.require or fluid.include would provide a very similar service to dojo.require, in that it would i) provide physical lookup for logical units that might be spread over several files, ii) be able to distinguish the situations where these were "exploded" into many smaller files for development, or few large files for production, and iii) automatically fetch in dependencies both in CSS and JS of a logical unit
[15:14:44 EDT(-0400)] <Bosmon> "I can't see any reason why this wouldn't work"
[15:15:27 EDT(-0400)] <Bosmon> Certainly even amongst 3 of us (Colin, Eli and me) we ran into lots of annoying situations at Paris where some of us had, for example, fluid-components deployed at some different physical depth in the filesystem, and had to spend the traditional tedious phase counting ../../../../ etc.
[15:15:37 EDT(-0400)] * theclown_afk (n=theclown@142.150.154.101) has left #fluid-work
[15:17:54 EDT(-0400)] <colinclark> Having a) some dependency management help, and and b) abstraction from physical path variations sure would be nice.
[15:18:11 EDT(-0400)] <colinclark> Bosmon: You were going to file a framework New Feature issue about this right?
[15:19:21 EDT(-0400)] <colinclark> Short-term framework priorities generally involve: 1) getting the that-ist style in play for our components; 2) implementing the DOM Binder to abstract the process of getting elements from using them; 3) Continuing to work on the client-side template renderer
[15:19:39 EDT(-0400)] <ecochran> I've always found that physical path issues can be minimized if you don't care about running off a local file system and you can just use absolute paths.
[15:19:51 EDT(-0400)] <colinclark> So towards the 0.7 time frame, this issue of builds and dependency management will be useful.
[15:20:12 EDT(-0400)] <ecochran> otherwise physical path issues are just part of the web game
[15:20:34 EDT(-0400)] <colinclark> ecochran; That sort of throws away the baby with the bath water in terms of the convenience of local web development.
[15:21:04 EDT(-0400)] <ecochran> I always work off a server
[15:21:44 EDT(-0400)] <colinclark> The problem with the "web game" is that we're building increasingly large and deep applications in which we use more dependencies than was typical in the old days.
[15:21:52 EDT(-0400)] <colinclark> The web game is changing for sure.
[15:21:59 EDT(-0400)] <ecochran> agreed
[15:22:12 EDT(-0400)] <ecochran> and I'd love to see a solution
[15:22:34 EDT(-0400)] <colinclark> And one that doesn't suck.
[15:22:43 EDT(-0400)] <ecochran> yes
[15:22:47 EDT(-0400)] <colinclark> Which makes for a hard set of problems to solve.
[15:23:56 EDT(-0400)] <ecochran> some of the problem is exacerbated by mimicking the multiple level directory structure of Java apps where no real work happens until your 3 directories down
[15:24:08 EDT(-0400)] <ecochran> I could see a much flatter structure
[15:24:22 EDT(-0400)] <ecochran> which would make debugging ../../../ much easier
[15:27:38 EDT(-0400)] <Bosmon> Yes
[15:27:57 EDT(-0400)] <Bosmon> The unfortunate reality is, each of us would probably be happiest with a slightly different set of paths
[15:28:11 EDT(-0400)] <Bosmon> Also, depending on even what "hat" we had on when we were dealing with the code
[15:28:28 EDT(-0400)] <ecochran> perhaps
[15:28:30 EDT(-0400)] <Bosmon> Anyway, yes, I will make a "New Feature" issue
[15:28:41 EDT(-0400)] <Bosmon> We are not planning to really look at this until probably after 0.6
[15:28:54 EDT(-0400)] <Bosmon> Until which we will be detained with "higher priority tasks"
[15:29:27 EDT(-0400)] <Bosmon> Although "in theory" most parts of this are fairly simple, apart from the bit about recognising "exploded/compressed" versions of the same stuff
[15:29:41 EDT(-0400)] <ecochran> A priority for me would be having a well written pattern for that with a little code tutorial!
[15:29:51 EDT(-0400)] <Bosmon> My blog posting is up now...
[15:29:59 EDT(-0400)] <Bosmon> Unfortunately the "more" links I put into it seem to have gone away
[15:30:04 EDT(-0400)] <ecochran> ah, I will read it over lunch
[15:30:04 EDT(-0400)] <Bosmon> So it is all one massive wodge
[15:30:07 EDT(-0400)] <ecochran> more links?
[15:30:26 EDT(-0400)] <Bosmon> There is this feature where you can split a posting up with sort of "internal chapters"
[15:30:34 EDT(-0400)] <Bosmon> It worked the very first time, and gave me a "continue reading" link
[15:30:38 EDT(-0400)] <Bosmon> But now they are gone...
[15:30:52 EDT(-0400)] <jhung> hmmm
[15:31:19 EDT(-0400)] <jhung> I'm going to take a look at that now...
[15:31:44 EDT(-0400)] <Bosmon> It looks like the "markings" for them are still in there in the markup if you look
[15:31:50 EDT(-0400)] <jhung> ok
[15:31:53 EDT(-0400)] <Bosmon> But they are no longer honoured when the post is rendered...
[15:32:19 EDT(-0400)] <Bosmon> Thanks, Jonathan
[15:32:54 EDT(-0400)] <jhung> yup. I see that. I'll file that in a jira so I don't forget about it.
[15:39:58 EDT(-0400)] <jhung> Antranig, I think the "more" break is supposed to be used once in a post. It acts like an excerpt where everything above the "more" is seen on the front page and everything after appears after the "Read more" link is clicked.
[15:40:24 EDT(-0400)] <jhung> There should be another macro that does what you want, but I can't seem to find it right now.
[15:52:38 EDT(-0400)] <jhung> I've filed a jira. Will look into the problem some more tomorrow. For now, we will have to live with long blog posts (just encourages everyone to be uber concise! ).
[15:53:23 EDT(-0400)] * jhung (n=Jon@142.150.154.211) has left #fluid-work
[15:54:20 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[16:04:10 EDT(-0400)] * Justin_o (n=Justin@142.150.154.235) has left #fluid-work
[16:10:29 EDT(-0400)] <colinclark> jhung: The new blog looks great!
[16:10:58 EDT(-0400)] <colinclark> I just updated Bosmon's article with the new URL for my document and set of templates on how to build a "unit."
[16:15:16 EDT(-0400)] * ecochran (n=ecochran@dhcp-169-229-212-100.LIPS.Berkeley.EDU) has left #fluid-work
[16:22:51 EDT(-0400)] * Jacob1 (n=Fluid@142.150.154.106) has joined #fluid-work
[16:47:21 EDT(-0400)] * Jacob1 (n=Jacob@142.150.154.106) has joined #fluid-work
[16:50:18 EDT(-0400)] * Jacob1 (n=Jacob@142.150.154.106) has left #fluid-work
[16:54:32 EDT(-0400)] * phiggins (n=dante@12.157.240.85) has joined #fluid-work
[17:35:06 EDT(-0400)] * ecochran (n=ecochran@dhcp-169-229-212-100.LIPS.Berkeley.EDU) has joined #fluid-work
[17:35:26 EDT(-0400)] <ecochran> Bosmon: excellent blog post!
[17:43:11 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[18:00:52 EDT(-0400)] * phiggins_ (n=dante@12.157.240.2) has joined #fluid-work
[18:01:53 EDT(-0400)] * phiggins_ (n=dante@12.157.240.2) has joined #fluid-work
[18:12:26 EDT(-0400)] <colinclark> ecochran; I missed the previous discusssion. I have made a first draft of a short tutorial on the "that" style:
[18:12:27 EDT(-0400)] <colinclark> http://wiki.fluidproject.org/display/fluid/How+to+Define+a+Unit
[18:12:40 EDT(-0400)] <colinclark> There's a cut-and-paste style template included.
[18:13:31 EDT(-0400)] <ecochran> colinclark: thanks
[18:13:40 EDT(-0400)] <ecochran> I'll definitely start there
[18:23:29 EDT(-0400)] <colinclark> ecochran: Any advice you have on how to clarify it is always appreciated.
[18:26:58 EDT(-0400)] <ecochran> colinclark: will do
[18:56:33 EDT(-0400)] * phiggins (n=dante@12.157.240.2) has joined #fluid-work
[22:09:36 EDT(-0400)] * phiggins (n=dante@12.157.240.2) has joined #fluid-work
[23:11:29 EDT(-0400)] * colinclark (n=colin@bas1-toronto09-1279621300.dsl.bell.ca) has joined #fluid-work
[23:55:12 EDT(-0400)] * colinclark (n=colin@bas1-toronto09-1279621300.dsl.bell.ca) has joined #fluid-work