fluid-work IRC Logs-2009-02-09

Owned by Fluid IRC Log Bot
Last updated: Feb 09, 2009Version comment
7 min read

[11:13:57 EST(-0500)] * JASIGLogBot (n=PircBot@jasigch.Princeton.EDU) has joined #fluid-work
[11:13:57 EST(-0500)] * Topic is '2 days to bug parade!' set by michelled on 2009-02-09 10:07:08 EST(-0500)
[11:18:29 EST(-0500)] * jayshao (n=jayshao@ool-45731e0f.dyn.optonline.net) has joined #fluid-work
[11:24:29 EST(-0500)] * apetro (n=apetro@12.164.139.7) has joined #fluid-work
[11:37:24 EST(-0500)] * ecochran (n=ecochran@dhcp-169-229-212-17.LIPS.Berkeley.EDU) has joined #fluid-work
[12:10:39 EST(-0500)] <colinclark> Justin_o, ecochran: I just committed a fix for FLUID-2202.
[12:10:59 EST(-0500)] <ecochran> thx... I'll take a look...
[12:11:07 EST(-0500)] <Justin_o> me too
[12:11:16 EST(-0500)] <colinclark> There was a bug in the way I was defining the SWFUpload setup decorator, which caused our gallery-specific options not to get merged in.
[12:12:11 EST(-0500)] <colinclark> This is probably a workaround, but I'll figure out what the underlying problem is in a moment. My goal for this particular approach was to allow an arbitrary set of decorators to be added to the uploader. In particular, to allow various bits of implementation-specific setup to happen.
[12:12:47 EST(-0500)] <colinclark> With this workaround, I think we only support one decorator at a time. Which is fine, since we only currently have one. But I'd still like it to be consistent with the implementation in other components such as Inline Edit.
[12:17:52 EST(-0500)] <ecochran> colinclark: looks good, works on my local server
[12:18:26 EST(-0500)] <ecochran> colinclark: spoke too soon
[12:18:34 EST(-0500)] <ecochran> I can browse but I can't upload
[12:19:04 EST(-0500)] <ecochran> the problem may be in how progress is being called
[12:19:18 EST(-0500)] <Justin_o> ecochran: I was able to upload using the server version with both f9 and f10
[12:19:23 EST(-0500)] <Justin_o> http://build.fluidproject.org:8080/sakai-imagegallery2-web/site/AddImages/#
[12:19:43 EST(-0500)] <ecochran> OK, let me see if my cache is cleared and if the server updated correctly
[12:24:18 EST(-0500)] <colinclark> ecochran: For the record, the problem was that I had misconfigured the default options for that decorator in Uploader.js. I had wrapped it in an array, which is unnecessary.
[12:24:35 EST(-0500)] <ecochran> colinclark and Justin_o : all good, tenacious server
[12:24:40 EST(-0500)] <colinclark> great
[12:25:04 EST(-0500)] <colinclark> Now we can see if b5 has any impact on the pause bug.
[12:25:29 EST(-0500)] <colinclark> ecochran: If it doesn't, are you figuring that we'll have to resort to only pausing once a file has finished being uploaded?
[12:26:11 EST(-0500)] <ecochran> Justin_o: I don't see another option... although I might be able to be a bit smart about it... if the file is no where near completely then I can assume that I can stop it
[12:26:22 EST(-0500)] <ecochran> I talked it through with Ray who felt it would be too fragile
[12:26:30 EST(-0500)] <ecochran> but I'm not convinced
[12:26:46 EST(-0500)] <ecochran> sorry, that comment was meant for colinclark
[12:27:04 EST(-0500)] <ecochran> I was in the middle of writing something to Justin and just kept typing (tongue)
[12:27:09 EST(-0500)] <colinclark> ha
[12:27:17 EST(-0500)] <colinclark> i'm sure Justin_o is interested too
[12:27:20 EST(-0500)] <ecochran> colinclark: do you have an opinion?
[12:27:26 EST(-0500)] <ecochran> too fragile?
[12:27:33 EST(-0500)] <colinclark> Well, it's an interesting assumption...
[12:27:56 EST(-0500)] <ecochran> Justin_o: do you have time to look at b5 with the server, specifically the pause bug (looking for the number...)
[12:28:03 EST(-0500)] <colinclark> if a file goes from being "nowhere near" to "almost" complete in a short amount of time, your assumption will likely fail, won't it?
[12:28:17 EST(-0500)] <ecochran> 822
[12:28:20 EST(-0500)] <colinclark> ecochran: Can you remind me of the exact nature of the bug as you understand it at this point?
[12:28:41 EST(-0500)] <Justin_o> ecochran: yep.. i will try to test that today
[12:30:34 EST(-0500)] <colinclark> ecochran: Erin and I are ready to chat whenever you and Daphne are.
[12:30:46 EST(-0500)] <ecochran> the exact nature is that the "Stop" command comes after the last chunk of the file is sent to the server. We fire off all the right Stopping events and shut the process down, some time after that the server sends the File Success message (confirmed by Ray) but the SWF doesn't report it and when you start the whole process up again, the SWF just hangs, gets stuck somewhere inside until you send it a stop
[12:31:09 EST(-0500)] <ecochran> Daphne is running a little late. I expected her... wait I hear keys... nope it's Oliver
[12:31:23 EST(-0500)] <ecochran> She emailed me that she'd be in by 9:30
[12:31:30 EST(-0500)] <colinclark> ok
[12:31:49 EST(-0500)] <colinclark> I have a uPortal Steering Commitee meeting at 10 am, but I can be a bit late if necessary.
[12:31:56 EST(-0500)] <ecochran> did my description make sense?
[12:32:02 EST(-0500)] <colinclark> ecochran: totally, yes
[12:32:29 EST(-0500)] <colinclark> And I think it confirms that your assumption would be fragile.
[12:32:33 EST(-0500)] <ecochran> the File Success is only slightly related. Ray and I had hoped that might be a work-around, but alas
[12:32:48 EST(-0500)] <colinclark> It would probably reduce the occurrence of the issue, but it wouldn't resolve it completely.
[12:33:03 EST(-0500)] <ecochran> I think that my assumption would only work if I could be tracking the upload times more closely
[12:33:25 EST(-0500)] <colinclark> But the challenge with tracking upload times is that it will still be foiled by short files
[12:33:39 EST(-0500)] <ecochran> which I would need to fix Fluid-1889
[12:33:52 EST(-0500)] <ecochran> well, I thought that small files, I would always let go to the end
[12:34:16 EST(-0500)] <colinclark> ecochran: Right, but how would you define "small?"
[12:34:21 EST(-0500)] <ecochran> basically I would need to know the average chunk size that was being passed to the server
[12:34:23 EST(-0500)] <colinclark> It would have to vary based on the connection.
[12:34:36 EST(-0500)] <ecochran> which I could get in a few passes
[12:34:54 EST(-0500)] <colinclark> And you'd need time to calculate the average chunk size, which would still allow the issue to happen in cases where you haven't yet been able to reliably determine that.
[12:35:43 EST(-0500)] <colinclark> I'm assuming that whatever approach we implement for FLUID-1889 will sit and listen to progress events for a bit, and then make an estimate. As the upload progressed, the estimate would become more accurate due to a larger sample size.
[12:39:27 EST(-0500)] <ecochran> colinclark: yep
[12:40:26 EST(-0500)] <ecochran> I wanted to do a test, because the chunksize my actually be fairly hardcoded in http upload, but I don't know... the speed at which the chunks are flying is another thing entirely.
[12:41:22 EST(-0500)] <ecochran> but the safest thing is to let the upload progress to the end of the file
[12:41:56 EST(-0500)] <ecochran> colinclark: I suspect that this is the reason that Flikr stopped allowing pausing in their implementation
[12:42:25 EST(-0500)] <colinclark> Perhaps, yes.
[12:50:54 EST(-0500)] <colinclark> ecochran: If we think a fix is going to be precarious, let's chat with Daphne and Erin about whether we should consider removing the pause feature altogether, or whether they're happy with the "wait for the current file to finish" approach.
[12:51:00 EST(-0500)] <Justin_o> colinclark, ecochran: here is the beta 5 compatibility page http://wiki.fluidproject.org/display/fluid/Upload+Compatibility
[12:51:08 EST(-0500)] <colinclark> Justin_o: thanks!
[12:51:25 EST(-0500)] <colinclark> Justin_o: I like the green. (smile)
[12:51:34 EST(-0500)] <Justin_o> green is good
[12:51:40 EST(-0500)] <Justin_o> let me know if you need more details
[12:51:50 EST(-0500)] <Justin_o> i haven't had a chance to test it on tiger yet
[12:52:07 EST(-0500)] <colinclark> Justin_o: Any other anecdotal information you can think of from your testing experience with it?
[12:52:08 EST(-0500)] <ecochran> colinclark: per Pause... agreed, per green ... agreed
[12:52:14 EST(-0500)] <colinclark> cool
[12:52:23 EST(-0500)] <ecochran> Justin_o: thx
[12:52:46 EST(-0500)] <Justin_o> ecochran: np
[12:52:54 EST(-0500)] <Justin_o> colinclark: nothing new that i can think of...
[12:53:04 EST(-0500)] <colinclark> ok
[12:53:18 EST(-0500)] <colinclark> Well, let's say something nice about Gyphie for a change.
[12:53:20 EST(-0500)] <colinclark> (tongue)
[12:53:28 EST(-0500)] <colinclark> ... trying to think of something ...
[12:53:48 EST(-0500)] <ecochran> Justin_o: the keyboard issues are the same as b4? or different
[12:54:05 EST(-0500)] <Justin_o> yes...they are the same as b4
[12:54:16 EST(-0500)] <colinclark> ecochran: One thing that may influence our decision is what Gears gives us in terms of pause-ability.
[12:54:20 EST(-0500)] <ecochran> that's what I assumed but I had to ask (wink)
[12:54:39 EST(-0500)] <colinclark> It occurs to me that it may or may not be possible to stop an upload mid-stream with Gears. I'll have to check.
[12:54:51 EST(-0500)] <ecochran> colinclark: interesting
[13:00:04 EST(-0500)] <colinclark> ecochran: Google kindly provides an API that is aligned with XMLHTTPRequest. The offer a slightly more expanded interface, but it conforms to all the basic methods.
[13:00:15 EST(-0500)] <colinclark> So we've got abort(), which should allow us to stop at any time.
[13:00:29 EST(-0500)] <colinclark> We'll just have to write the code to start up correct again at the right spot.
[13:01:28 EST(-0500)] <ecochran> colinclark: do we get callbacks for each chunk that gets sent? And if so, can we abort when a chunk completes before the next chunk is sent (this is what seems to be missing from SWFUpload)
[13:02:09 EST(-0500)] <colinclark> ecochran: Yep, there's the onprogress event.
[13:02:21 EST(-0500)] <colinclark> Apparently this is a "non-normative" part of the XMLHTTPRequest spec.
[13:02:37 EST(-0500)] <colinclark> But Gears provides it, which is great.
[13:02:51 EST(-0500)] <ecochran> awesome
[13:03:27 EST(-0500)] <ecochran> I wonder if I didn't Pause until the next Progress event from the SWF, if that would fix the problem?
[13:26:28 EST(-0500)] <colinclark> ecochran: It's definitely worth trying it out.
[13:45:25 EST(-0500)] <colinclark> ecochran: Gears is so fantastic, in that it lets you upload a portion of a file and then resume it mid-stream later. So you could do part of a file, bail (eg. "gotta catch a flight"), then come back and resume where you were later.
[13:46:21 EST(-0500)] <ecochran> wow!
[13:46:23 EST(-0500)] <ecochran> very cool
[13:46:43 EST(-0500)] <ecochran> of course on the server you'd need some kind of smart "partial file" store
[13:46:48 EST(-0500)] <ecochran> but that is very cool!
[13:47:42 EST(-0500)] <colinclark> ecochran: Yep, exactly.
[13:48:38 EST(-0500)] <colinclark> As far as I can tell, it will also run seamlessly with Gears' offline support, too.
[13:48:48 EST(-0500)] <colinclark> Lots of post-1.0 possibilities here.
[15:17:41 EST(-0500)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[15:43:16 EST(-0500)] * anastasiac_ (n=team@142.150.154.189) has joined #fluid-work
[16:03:14 EST(-0500)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[16:05:56 EST(-0500)] * laurelw (n=Laurel@142.150.154.178) has left #fluid-work
[16:11:01 EST(-0500)] * anastasiac_ (n=team@142.150.154.189) has joined #fluid-work
[16:12:41 EST(-0500)] * jayshao (n=jayshao@ool-45731e0f.dyn.optonline.net) has joined #fluid-work
[16:36:21 EST(-0500)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[17:46:47 EST(-0500)] * clown (n=clown@142.150.154.101) has left #fluid-work
[18:00:13 EST(-0500)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[18:53:20 EST(-0500)] * ecochran (n=ecochran@dhcp-169-229-212-17.LIPS.Berkeley.EDU) has joined #fluid-work
[23:51:54 EST(-0500)] * colinclark (n=colin@bas2-toronto09-1176131452.dsl.bell.ca) has joined #fluid-work