fluid-work IRC Logs-2010-01-11

[04:53:32 EST(-0500)] * sveto (n=sveto@62.44.108.2) has joined #fluid-work
[04:54:34 EST(-0500)] * boyan (n=boyan@62.44.108.2) has joined #fluid-work
[06:45:28 EST(-0500)] * sveto (n=sveto@62.44.108.2) has left #fluid-work
[06:50:35 EST(-0500)] * sveto (n=sveto@62.44.108.2) has joined #fluid-work
[08:20:02 EST(-0500)] * laurel (n=Laurel@142.150.154.178) has joined #fluid-work
[08:30:30 EST(-0500)] * laurel (n=Laurel@142.150.154.178) has left #fluid-work
[08:32:02 EST(-0500)] * athena (n=athena@adsl-76-250-193-123.dsl.wlfrct.sbcglobal.net) has joined #fluid-work
[08:46:37 EST(-0500)] * Justin_o (n=Justin@142.150.154.171) has joined #fluid-work
[09:00:33 EST(-0500)] * jessm (n=Jess@c-71-232-3-151.hsd1.ma.comcast.net) has joined #fluid-work
[09:12:57 EST(-0500)] * colinclark (n=colin@bas2-toronto09-1176130598.dsl.bell.ca) has joined #fluid-work
[09:16:36 EST(-0500)] * yura (n=yura@user149-16.wireless.utoronto.ca) has joined #fluid-work
[09:16:56 EST(-0500)] * anastasiac (n=team@142.150.154.189) has joined #fluid-work
[09:30:36 EST(-0500)] * sveto (n=sveto@62.44.108.2) has left #fluid-work
[09:33:09 EST(-0500)] * sveto (n=sveto@62.44.108.2) has joined #fluid-work
[09:39:33 EST(-0500)] * clown (n=clown@142.150.154.190) has joined #fluid-work
[09:45:54 EST(-0500)] * andreauoc (n=carlos@120.Red-213-96-26.staticIP.rima-tde.net) has joined #fluid-work
[10:33:54 EST(-0500)] * sveto (n=sveto@62.44.108.2) has left #fluid-work
[11:00:08 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[11:11:30 EST(-0500)] * michelled (n=michelle@142.150.154.101) has joined #fluid-work
[11:36:37 EST(-0500)] * elicochran (n=elicochr@dhcp-169-229-212-16.LIPS.Berkeley.EDU) has joined #fluid-work
[11:39:29 EST(-0500)] * boyan (n=boyan@62.44.108.2) has left #fluid-work
[11:50:42 EST(-0500)] <jamon> anyone seen this? http://www.microsoft.com/downloads/details.aspx?FamilyID=8e6ac106-525d-45d0-84db-dccff3fae677&amp;displaylang=en
[11:51:13 EST(-0500)] <jamon> shows a webpage simultaneously as rendered in IE 6,7,8
[11:56:51 EST(-0500)] <athena> ooh nice
[11:56:58 EST(-0500)] <athena> has it worked well for you jamon?
[11:57:24 EST(-0500)] <jamon> i haven't got a windows machine to try it with athena
[11:57:32 EST(-0500)] <athena> gotcha
[11:58:04 EST(-0500)] <athena> i have a windows vm
[11:58:20 EST(-0500)] <athena> but i'm strongly opposed to actually using it
[11:58:30 EST(-0500)] <jamon> haha
[11:59:04 EST(-0500)] <athena> i'd prefer things actually work on my machine without having to feed another OS RAM that i have better uses for
[12:00:42 EST(-0500)] <jamon> i think there's a way to pare down xp to about 350mb of ram
[12:00:51 EST(-0500)] <jamon> for a vm, that wouldn't be bad
[12:01:09 EST(-0500)] <athena> yeah, that's not terrible
[12:03:55 EST(-0500)] <jamon> http://www.nliteos.com/ is the tool
[12:10:48 EST(-0500)] * jimeng (n=jimeng@141-213-171-007.vpn.umnet.umich.edu) has joined #fluid-work
[12:11:21 EST(-0500)] * andreauoc (n=carlos@120.Red-213-96-26.staticIP.rima-tde.net) has left #fluid-work
[12:12:29 EST(-0500)] * yura (n=yura@142.150.154.132) has joined #fluid-work
[12:15:34 EST(-0500)] <jimeng> Can anybody give advice about debugging with the flash component in the uploader?
[12:16:38 EST(-0500)] <jimeng> My java code is (I think) returning a 201 success response, but it shows up in the uploader as -200 ( which is HTTP_ERROR ) with a message of "201".
[12:17:59 EST(-0500)] <jimeng> So I'd like to look at what exactly the flash component gets back (if that's possible) but the requests/responses for the post's from the uploader do not show up in firebug.
[12:18:04 EST(-0500)] <jimeng> Any suggestions?
[12:18:19 EST(-0500)] <jimeng> And, BTW, Good Morning All!
[12:18:30 EST(-0500)] <jimeng> or Good Afternoon!
[12:22:10 EST(-0500)] <Justin_o> jimeng: hmm... i'm not too sure... i just did a quick google search for actionscript debugger and i got this one http://www.actionscript.org/resources/articles/207/1/Trace-and-debug-ActionScript-from-your-browser/Page1.html
[12:22:42 EST(-0500)] <Justin_o> not sure how much help that will be for you though
[12:31:33 EST(-0500)] <colinclark> jimeng: I've never had a whole lot of luck debugging Flash movies, since as you say they don't use the browser's transport mechanism. I'd probably suggest using a debugging proxy of some kind and watching requests/responses that way.
[12:31:39 EST(-0500)] <colinclark> But HTTP 200 is success, not an error.
[12:31:41 EST(-0500)] <colinclark> http://en.wikipedia.org/wiki/List_of_HTTP_status_codes
[12:31:53 EST(-0500)] <colinclark> 200 is "OK"
[12:33:07 EST(-0500)] <colinclark> elicochran might have some insights about how Uploader handles errors. I seem to remember him telling me about a few quirks awhile back.
[12:33:37 EST(-0500)] <elicochran> elicochran is catching up on the conversation
[12:34:37 EST(-0500)] <jimeng> jimeng is catching up too. Clarifying: the status code is "-200" rathern than "200"
[12:37:03 EST(-0500)] <colinclark> ah, i didn't even see the "" there in your message-it was at the end of a line
[12:37:51 EST(-0500)] <elicochran> jimeng: It might be that SWFUpload interprets anything which isn't a 200 as an error. Still poking around.
[12:41:07 EST(-0500)] <elicochran> jimeng and colinclark: the SWFUpload is insanely limited in the kind of data that it will pass through from the server. It may be a limitation of Flash... I can't remember. So even though the server may send back wordy and useful status messages, the Flash component only reports status numbers on errors. (Success messages do pass along data... go figure.)
[12:41:19 EST(-0500)] <elicochran> But this doesn't seem to be what you're encountering.
[12:42:41 EST(-0500)] <colinclark> Looks like this might be an issue with SWFUpload, jimeng.
[12:42:42 EST(-0500)] <colinclark> http://swfupload.org/forum/generaldiscussion/1860
[12:42:51 EST(-0500)] <jimeng> elicochran: I will try changing the success code from the server to "200", though I'm not sure I can actually do that
[12:43:27 EST(-0500)] <colinclark> 201 looks like the correct semantic
[12:43:46 EST(-0500)] <elicochran> it sure does... but SWFUpload doesn't seem to like it
[12:43:49 EST(-0500)] <colinclark> But it's pretty clear from googling "SWFUpload HTTP 201" that it returns an error when it encounters anything but a 200 response code
[12:44:00 EST(-0500)] <colinclark> I'll take a look at the actual implementation to confirm.
[12:44:04 EST(-0500)] <colinclark> And then we can file a bug with them.
[12:44:17 EST(-0500)] <jimeng> Thanks. That's a big help
[12:45:23 EST(-0500)] <elicochran> colinclark: did you notice that after a year of no development that SWFUpload is on the verge of a 2.5 release?
[12:45:37 EST(-0500)] <colinclark> i didn't notice that, no
[12:45:42 EST(-0500)] <colinclark> what's new in 2.5?
[12:46:21 EST(-0500)] <colinclark> Most notable feature seems to be client-side image resizing
[12:46:25 EST(-0500)] <elicochran> doesn't look like much... most improving the "look" of the Upload button by supporting....
[12:46:28 EST(-0500)] <elicochran> you got it
[12:46:29 EST(-0500)] <colinclark> They're adding features we wouldn't even want in many cases
[12:46:31 EST(-0500)] <colinclark> cool
[12:46:52 EST(-0500)] <elicochran> I haven't been watching the space
[12:47:07 EST(-0500)] <elicochran> just surprised
[12:47:18 EST(-0500)] <colinclark> I don't know if I ever told you, elicochran, but I managed to get a no-Flash version of Uploader working.
[12:47:25 EST(-0500)] <colinclark> It's still got some more bug that need to be ironed out
[12:47:30 EST(-0500)] <colinclark> but it is the start of Freedom
[12:47:42 EST(-0500)] <elicochran> using the HTML5 stuff?
[12:50:17 EST(-0500)] <jamon> speaking of new releases (not to change the subject) but v8 is in debian testing and unstable: http://packages.debian.org/squeeze/libv8-2.0.3
[12:50:32 EST(-0500)] <jamon> (64bit too)
[12:50:47 EST(-0500)] * nkhan26 (n=chatzill@net1.senecac.on.ca) has joined #fluid-work
[12:50:48 EST(-0500)] <colinclark> jamon: Cool!
[12:51:42 EST(-0500)] <colinclark> I'm looking at SWFUpload's source and there may be a way to configure which HTTP codes are interpreted as successful
[12:51:49 EST(-0500)] <colinclark> Though I can't imagine why they wouldn't just do this for us
[12:53:10 EST(-0500)] <colinclark> From SWFUpload's document: " The http_success setting allows uploadSuccess to be fired for HTTP status codes other than 200. In this case no server data is available from the Flash Player. "
[12:53:44 EST(-0500)] <colinclark> Looks like you pass it an array of codes that denote success.
[12:53:48 EST(-0500)] <colinclark> This is just tremendously dorky
[12:53:52 EST(-0500)] <colinclark> But good news for jimeng.
[12:54:40 EST(-0500)] <elicochran> if I remember, the way that they suggest handing verbose error codes was to return everything as a 200 (success) even errors and include your custom error messages in the server data that gets returned
[12:55:02 EST(-0500)] <jimeng> colinclark: do you have a URL to that document?
[12:55:17 EST(-0500)] <colinclark> yeah, they're saying that only 200 will report real error messages, elicochran
[12:55:19 EST(-0500)] <colinclark> jimeng: Yep
[12:55:25 EST(-0500)] <colinclark> http://demo.swfupload.org/Documentation/
[12:55:52 EST(-0500)] <colinclark> So, here's how you'd set this setting on an instance of the Uploader, jimeng:
[12:56:03 EST(-0500)] <colinclark> Once you've instantiated your Uploader
[12:56:04 EST(-0500)] <colinclark> say like this:
[12:56:19 EST(-0500)] <colinclark> var myUploader = fluid.uploader(container, options);
[12:56:20 EST(-0500)] <elicochran> colinclark: this is feeling more and more like a Flash bug... since it's so odd that the only status that will return useful data is a 200
[12:56:22 EST(-0500)] <colinclark> then you can access the swfUpload instance itself like this:
[12:57:19 EST(-0500)] <colinclark> myUploader.uploadManager.swfUploader.setHTTPSuccess([201]);
[12:57:21 EST(-0500)] <colinclark> That should do it
[12:57:43 EST(-0500)] <colinclark> elicochran: Yeah, I think that part of it is a Flash bug
[12:57:57 EST(-0500)] <colinclark> Seems to me it's still SWFUpload's bug that they don't support valid HTTP success codes out of the box
[12:58:24 EST(-0500)] <colinclark> built-in browser multifile uploads are gonna be great
[12:58:39 EST(-0500)] <jimeng> Looks easy enough. Thanks, colinclark, elicochran and Justin_o
[12:58:52 EST(-0500)] <jimeng> I will report back on what I find out.
[12:59:09 EST(-0500)] <colinclark> cool. good luck, jimeng
[14:02:48 EST(-0500)] <jimeng> That approach worked perfectly. Since we already had code to instantiate the uploader, fixing this required a one-line addition to the js file:
[14:02:49 EST(-0500)] <jimeng> myUploader.uploadManager.swfUploader.setHTTPSuccess([201]);
[14:03:07 EST(-0500)] <jimeng> Thanks to all for your help with this
[14:03:56 EST(-0500)] <jimeng> Once I work out a few more details of how we handle success, it will be onward and upward to the rich-text editor!
[14:04:18 EST(-0500)] <jimeng> elicochran: Thanks
[14:19:44 EST(-0500)] <elicochran> jimeng: you're welcome
[14:19:55 EST(-0500)] <elicochran> jimeng: what project is this working going into?
[14:21:04 EST(-0500)] <jimeng> Gonzalo and I are working on a tool in Sakai 2 that provides views of resources and also does most of what the current resources tool does. It doesn't have a name yet
[14:21:58 EST(-0500)] <elicochran> jimeng: sounds cool... is this just for local use or for the community?
[14:22:03 EST(-0500)] <jimeng> It is a much nicer UI and has better performance characteristics because almost everything is handled through Ajax requests
[14:22:12 EST(-0500)] <elicochran> jimeng: the richtext is also for this?
[14:22:17 EST(-0500)] <jimeng> It will be available for the community
[14:22:42 EST(-0500)] <jimeng> But we are just now finishing up the entity provider work
[14:22:57 EST(-0500)] <jimeng> Then we go through eval of what people want to do with that
[14:23:07 EST(-0500)] <elicochran> jimeng: let me know when you have something to show... I'd love to see it
[14:23:11 EST(-0500)] <elicochran> thx
[14:23:17 EST(-0500)] <jimeng> And that will result in specs for the actual UI
[14:23:20 EST(-0500)] <jimeng> We will
[14:23:22 EST(-0500)] <jimeng> Thanks
[14:51:48 EST(-0500)] * colinclark (n=colin@bas2-toronto09-1176130598.dsl.bell.ca) has joined #fluid-work
[16:33:12 EST(-0500)] * athena (n=athena@adsl-76-250-193-123.dsl.wlfrct.sbcglobal.net) has joined #fluid-work
[16:49:03 EST(-0500)] * clown_afk (n=clown@142.150.154.101) has joined #fluid-work
[16:53:24 EST(-0500)] * clown_ (n=clown@142.150.154.190) has joined #fluid-work
[17:11:34 EST(-0500)] * anastasiac (n=team@142.150.154.189) has left #fluid-work
[17:19:32 EST(-0500)] * Bosmon (n=Bosmon@eccr224-158-dhcp.colorado.edu) has joined #fluid-work
[17:20:06 EST(-0500)] <Bosmon> This is probably just a distraction at this point, but I just wanted to throw into the channel for the record the fact that the time might finally be "nigh" to start considering doing something about the ancestral http://issues.fluidproject.org/browse/FLUID-958
[17:20:33 EST(-0500)] <Bosmon> So, I am reviewing the external event contract for Pager and InlineEdit, which seem to be our main flagship "model-bearing" components
[17:20:38 EST(-0500)] <Bosmon> They do not entirely agree...
[17:20:44 EST(-0500)] <Bosmon> Although they are fairly close
[17:21:15 EST(-0500)] <Bosmon> InlineEdit throws an event named "modelChanged", with signature (newModel, oldModel, source) - where "source" is actually the DOM element responsible for the change
[17:21:41 EST(-0500)] <Bosmon> Pager throws an event "onModelChange" with signature (newModel, oldModel, that) where "that" is the Pager itself
[17:22:11 EST(-0500)] <Bosmon> I think Pager's event is incorrectly named since it does not permit cancellation of the change which I think is a crucial general part of an "on" event
[17:22:54 EST(-0500)] <Bosmon> Our support for "event boiling" I think will be crucial since there will no doubt be lots of people to whom these signatures are not the best - but we at least need to centralise on a base core policy which is consistent
[17:23:07 EST(-0500)] <Bosmon> A "new thing" which we can now throw into the general mix of arguments is a "change list"
[17:23:41 EST(-0500)] <Bosmon> The "new ChangeApplier" can keep track of a whole stack of primitive changeRequest objects which are built up during a model-altering transaction, and fire out the entire set of them to people who are interested
[17:24:20 EST(-0500)] <Bosmon> In the "new framework" all of this stuff will be automated, and there will be a "default linkage" between the "modelChanged" listeners of the applier of a model-bearing component, and an external event also called "modelChanged"
[17:26:09 EST(-0500)] <Bosmon> The applier itself naturally knows nothing about the thing which we currently have in the 3rd argument position in external "modelChanged", which is variously the DOM element, or the overall "that"
[17:36:22 EST(-0500)] <colinclark> just catching up, Bosmon
[17:37:39 EST(-0500)] <colinclark> Bosmon: Ah, this is really interesting
[17:38:53 EST(-0500)] <colinclark> so, that third argument for InlineEdit is actually, what, the text field DOM node in which the change was entered?
[17:39:07 EST(-0500)] <Bosmon> Yeah, that's right
[17:39:20 EST(-0500)] <Bosmon> That seemed a sort of relevant piece of information, for something as low-level as inlineEdit
[17:39:28 EST(-0500)] <Bosmon> But I imagine doesn't make global sense as a policy
[17:39:44 EST(-0500)] <Bosmon> I'm starting to wonder whether this sort of thing really can be fully automated, at least for this release
[17:40:02 EST(-0500)] <Bosmon> Especially looking at the quite intricate workflow by which "New Pager" initialises first, its model, and second, its applier
[17:40:30 EST(-0500)] <Bosmon> So for now, I have written this 1-line "relay"
[17:40:32 EST(-0500)] <Bosmon> applier.modelChanged.addListener("!*", function(newModel, oldModel, changes) {
[17:40:32 EST(-0500)] <Bosmon> that.events.modelChanged.fire(newModel, oldModel, that);
[17:40:32 EST(-0500)] <Bosmon> });
[17:41:15 EST(-0500)] <Bosmon> I guess it is a bit like the "DOM binder" - people can use top-level functionality easily, but can subscribe to lower-level events if they are interested
[17:42:06 EST(-0500)] <Bosmon> It doesn't seem completely "slick" yet, but I'm still a bit nervous of a "one size fits all policy"
[17:42:35 EST(-0500)] <Bosmon> Generally there seems an expectation that the 3rd arg of "modelChanged" is of something of relevance to the identity of the firer of the event
[17:43:10 EST(-0500)] <Bosmon> In the case of InlineEdit, this information is actually "indispensible" - there is no way "after the fact" that the exact identity of the responsible DOM element could be discovered, by boiling
[17:43:36 EST(-0500)] <colinclark> yeah
[17:43:54 EST(-0500)] <colinclark> i think everything you've said so far is right
[17:44:03 EST(-0500)] <Bosmon> Whereas for the pager, what we put in 3rd place is rather notional...
[17:44:43 EST(-0500)] <colinclark> we can probably hold off a bit longer until we've implemented a few more examples, and as you say there's always the lower level change events if needed
[17:44:50 EST(-0500)] <Bosmon> Anyway, now we have "really functional" appliers, the overal contract for dealing with models themselves should be pretty clear
[17:44:57 EST(-0500)] <colinclark> interesting that your last comment on this ticket was almost exactly a year ago
[17:45:00 EST(-0500)] <Bosmon> yes
[17:45:29 EST(-0500)] <Bosmon> But there are lots of things that we wrote "in the past" which can be seen as a kind of "shorthand" for things that we can now do via the applier
[17:45:43 EST(-0500)] <Bosmon> So, things like "top-level" updateModel API, and "top-level" modelChanged notification
[17:46:15 EST(-0500)] <colinclark> I'm pretty excited to use the ChangeApplier to implement the data access layer for Engage. Between the declarative DataSourceSpec (or whatever we'll call it) and the ChangeApplier, it looks like we can totally "automate" all the mechanics of making Ajax requests and the like
[17:46:23 EST(-0500)] <Bosmon> Yes
[17:46:33 EST(-0500)] <Bosmon> The "model calculus" will also be exciting
[17:46:40 EST(-0500)] <colinclark>
[17:46:43 EST(-0500)] <Bosmon> We should start looking at these "mapping documents" that we are already starting to accumulate
[17:46:59 EST(-0500)] <colinclark> yeah, yura, justin and i chatted a bit about them the other day
[17:47:05 EST(-0500)] <colinclark> and how to correct them a bit
[17:47:10 EST(-0500)] <Bosmon> I mean, that is pretty much "immediate" work, right? I assume this is closely related to what we want to deliver for Uuuug
[17:47:18 EST(-0500)] <colinclark> it's entirely immediate, yes
[17:47:26 EST(-0500)] <colinclark> as in, tomorrow immediate
[17:47:27 EST(-0500)] <colinclark>
[17:47:29 EST(-0500)] <Bosmon>
[17:47:46 EST(-0500)] <Bosmon> Well then, not quite the Churchillian "ACTION THIS DAY"
[17:48:28 EST(-0500)] <colinclark>
[17:50:14 EST(-0500)] <Bosmon> So.... in terms of what people "might have expected" from an event named "onModelChange" on "old Pager", this would now be available in what has been implemented as "postGuards"
[17:50:38 EST(-0500)] <Bosmon> These are guards which execute AFTER a stack of model changes have been processed against a model, but before the complete state of the new model has been committed
[17:50:38 EST(-0500)] <colinclark> In terms of their ability to prevent a change from occurring, you mean?
[17:50:40 EST(-0500)] <Bosmon> Yes
[17:50:48 EST(-0500)] <colinclark> That's really great
[17:51:03 EST(-0500)] <Bosmon> "postGuards" are essentially a transactional concept, although they could in theory I guess apply to just a single change
[17:51:35 EST(-0500)] <colinclark> is it identified as post guard by the ! prefix in the path?
[17:51:35 EST(-0500)] <Bosmon> I think one final courtesy we need in the changeApplier is a "contund" flag which can be set on an ADD change
[17:51:45 EST(-0500)] <Bosmon> No, postGuards now exist at top level inside the applier
[17:51:53 EST(-0500)] <Bosmon> applier.postGuards.addListener("!*", modelConformingGuard);
[17:51:57 EST(-0500)] <colinclark> ah
[17:52:00 EST(-0500)] <Bosmon> So, here is a registration of a "postGuard"
[17:52:08 EST(-0500)] <Bosmon> Which is BOTH transactional, AS WELL as being a postGuard
[17:52:20 EST(-0500)] <colinclark> makes sense
[17:52:25 EST(-0500)] <Bosmon> As I mentioned, in theory there could be a non-transactional postGuard, although it would not really offer very much value
[17:52:36 EST(-0500)] <colinclark> what happened to the idea of having an options argument to addListener()?
[17:52:39 EST(-0500)] <colinclark> Didn't need it?
[17:52:44 EST(-0500)] <Bosmon> No, that was implemented too
[17:53:08 EST(-0500)] <Bosmon> I just took it away here, since I realised that the "priority" concept was actually no longer needed for Pager once we have PostGuards
[17:53:13 EST(-0500)] <colinclark> is transactionality an option? I always prefer something explicit to a special symbol like ! if it's possible
[17:53:15 EST(-0500)] <Bosmon> Since the "post-ness" offers all of the necessary sequencing
[17:53:33 EST(-0500)] <Bosmon> Yes, just a few minutes ago I rewrote these lines from something that looked like this:
[17:53:52 EST(-0500)]

[17:53:57 EST(-0500)] <Bosmon> The two forms are completely equivalent
[17:54:05 EST(-0500)] <colinclark> cool
[17:54:10 EST(-0500)] <colinclark> that's great!
[17:54:38 EST(-0500)] <Bosmon> It might well be that the "priority" feature never ends up being used....
[17:54:41 EST(-0500)] <Bosmon> But, it is there now
[17:55:55 EST(-0500)] <colinclark> Well, the new ChangeApplier is really shaping up, dude
[19:28:51 EST(-0500)] * jimeng (n=jimeng@67-194-68-67.wireless.umnet.umich.edu) has joined #fluid-work
[19:39:28 EST(-0500)] * jimeng_ (n=jimeng@141-213-171-095.vpn.umnet.umich.edu) has joined #fluid-work
[21:24:50 EST(-0500)] * yura (n=yura@bas3-toronto06-2925097158.dsl.bell.ca) has joined #fluid-work