fluid-work IRC Logs-2011-02-08

[09:11:09 CST(-0600)] <michelled> good morning mlam
[09:11:21 CST(-0600)] <mlam> morning michelled
[09:11:30 CST(-0600)] <michelled> I put some comments on your fork - did github email you?
[09:12:08 CST(-0600)] <mlam> Yah, it did. I got 3 emails this morning
[09:12:27 CST(-0600)] <michelled>
[09:12:50 CST(-0600)] <michelled> mlam: once you've addressed those comments I think I'd like to see it in action if you're willing to give me a demo
[09:13:08 CST(-0600)] <mlam> Ok, definitely
[09:13:18 CST(-0600)] <michelled> cool, thx
[09:13:53 CST(-0600)] <mlam> np. I'll let you know as soon as the changes are in
[09:31:22 CST(-0600)] <michelled> heidi_: am I right that I need to push the patches for 4037, 4029 and 3837?
[09:31:58 CST(-0600)] <heidi_> michelled 4037 is in a branch on colin's github
[09:32:17 CST(-0600)] <heidi_> 4029 and 3837 are just patches in jira right now
[09:32:57 CST(-0600)] <michelled> heidi_: is there a dependency between 4037, 4029 and 3837?
[09:33:51 CST(-0600)] <jamon> fluid-everyone: wiki should be restored, all except anastasiac's attachments from yesterday
[09:34:00 CST(-0600)] <heidi_> 3837 reqs 4037 and 4029 michelled
[09:34:05 CST(-0600)] <anastasiac> jamon, actually, they got in before your backup, so I'm good
[09:34:10 CST(-0600)] <jamon> great
[09:34:40 CST(-0600)] <heidi_> 4037 - scroller component, 4029 - progress bar tweek, 3837 - uploader using scroller component and looking nice with better html/css
[09:35:45 CST(-0600)] <michelled> ok, so I should get 4029 in
[09:35:57 CST(-0600)] <michelled> once 4037 is ready we can make sure it gets in
[09:36:09 CST(-0600)] <michelled> and then lastly we put 3837 in - does that seem right heidi_ ?
[09:36:37 CST(-0600)] <heidi_> michelled yep - and 4037 can go in now
[09:37:15 CST(-0600)] <heidi_> there's a special case we need to think about, but it doesn't need to hold back that stuff
[09:53:01 CST(-0600)] <mlam> michelled: I've refactored and added more unit tests
[09:54:07 CST(-0600)] <mlam> With regards to your note about the similarly structured loops, I'm not sure what I could refactor out here since we are looking for specific file types to convert to mime types
[10:15:08 CST(-0600)] <mlam> fluid-everyone: I'm running into an issue with the Uploader that could simply be solved by adding another option in the API. I'm looking for some advice on what to do. Here's the situation...
[10:15:49 CST(-0600)] <mlam> The SWF uploader accepts standard file type extensions for file exclusion in the file dialog. ie. *.img, *.gif, etc
[10:16:07 CST(-0600)] <mlam> Whereas the HTML5 uploader only accepts mime types for file exclusions
[10:16:50 CST(-0600)] <mlam> Depending on what version of the uploader we're using, a file type to mime type conversion needs to make so that the uploader can properly exclude files.
[10:17:07 CST(-0600)] <mlam> *needs to be made
[10:18:09 CST(-0600)] <mlam> So the question is: Do we have code to do this conversion every time the HTML5 uploader is used? Or do we introduce a new mimeType option in the queue settings?
[10:19:32 CST(-0600)] <mlam> Another question is, is an API change something we want for the 1.3.1 release?
[10:22:54 CST(-0600)] <heidi_> mlam can the uploader know which version is being used? i guess by checking browser or?
[10:22:54 CST(-0600)] <michelled> mlam: I think I like the idea of a mimeType option in queue settings since it seems like a better API but I can be convinced otherwise. do you think the user of the queue would find mime type or the swf style file type more natural?
[10:23:11 CST(-0600)] <mlam> heidi_: yes, through progressive enhancement
[10:23:52 CST(-0600)] <michelled> brb
[10:24:21 CST(-0600)] <mlam> I think file types seem more natural as that's what you see more often
[10:28:51 CST(-0600)] <colinclark> mlam: let me catch up after standup
[10:28:59 CST(-0600)] <mlam> ok
[10:53:59 CST(-0600)] <colinclark> Hi mlam
[10:54:04 CST(-0600)] <colinclark> I just re-read your question
[10:54:16 CST(-0600)] <colinclark> I think there are a few questions we should pull apart
[10:55:17 CST(-0600)] <colinclark> I think we want to provide a seamless API for our users when they are specifying file types--end users who are specifying options to the Uploader probably shouldn't have to know about these format differences.
[10:55:25 CST(-0600)] <colinclark> So I guess the first question is:
[10:55:47 CST(-0600)] <colinclark> 1. What's the contract we want to share with our users in regards to configuring file type exclusions for the Uploader?
[10:55:54 CST(-0600)] <colinclark> Another question:
[10:56:45 CST(-0600)] <colinclark> 2. How should we factor the "options chewing" code for file type exclusions? In other words, what sorts of functions and data structures do we need in order to convert from one format to another, internally?
[10:57:07 CST(-0600)] <colinclark> Do those questions make sense, and do they seem roughly like the ones we need to answer?
[10:57:25 CST(-0600)] <mlam> colinclark: Yes and yes
[10:57:49 CST(-0600)] <colinclark> Okay, so the first question might well have two different answers, I'm not sure
[10:58:14 CST(-0600)] <colinclark> Can you paste an example of the two different formats into the channel for us, just so it's concrete?
[10:58:32 CST(-0600)] <mlam> The first question is difficult. Because we don't know how long Flash will be fully supported.
[10:58:34 CST(-0600)] <mlam> Sure thing
[10:58:40 CST(-0600)] <colinclark> In other words, what do file type exclusions look like for SWFUpload, and what do they look like for the <input> element?
[10:59:08 CST(-0600)] <colinclark> I think probably the way to first answer the first question is to decide if one format is noticeably better than the other
[10:59:28 CST(-0600)] <mlam> for SWFUpload, audio file types can look like any of the following: .aac", ".aif", ".flac", ".iff", ".m4a", ".m4b", ".mid", ".midi", ".mp3", ".mpa", ".mpc", ".oga", ".ogg", ".ra", ".ram", ".snd", ".wav", ".wma"
[10:59:33 CST(-0600)] <colinclark> I think our concrete implementations matter less here--we could even choose a format that none of them support, and configure both
[10:59:42 CST(-0600)] <colinclark> oh, wait
[10:59:48 CST(-0600)] <mlam> in HTML5, audio mime types will look like this audio/*
[10:59:49 CST(-0600)] <colinclark> Is that exactly what the option looks like?
[10:59:57 CST(-0600)] <colinclark> Can you give us a real example?
[11:00:10 CST(-0600)] <colinclark> I was under the impression that SWFUpload took a single string, with comma-separated file extensions?
[11:00:30 CST(-0600)] <mlam> Yes, sorry, it was just a generic example...i'll give a more concrete example
[11:00:37 CST(-0600)] <colinclark> Give us a real example for, say, excluding everything except JPGs, PNGs, and GIFs.
[11:01:38 CST(-0600)] <mlam> I think exclusion isn't the best word when we're talking about file types. It's actually the other way around. It's file type acceptance
[11:01:49 CST(-0600)] <colinclark> ok
[11:01:49 CST(-0600)] <colinclark> cool
[11:01:52 CST(-0600)] <colinclark> my bad
[11:02:34 CST(-0600)] <mlam> for instance, if we wanted the file dialog to only display jpgs, pngs, and gifs, we would set the fileType in the queueSettings to: ".jpg,.png,*.gif"
[11:02:47 CST(-0600)] <mlam> that 's for the SWFUpload
[11:02:59 CST(-0600)] <colinclark> Okay, so it's a comma-delimited String for SWFUpload
[11:03:12 CST(-0600)] <mlam> for HTML5, we would only expect a mime type. for the above equivalent, we would set the fileType to "image/*"
[11:03:16 CST(-0600)] <colinclark> aha
[11:03:17 CST(-0600)] <mlam> yes
[11:03:30 CST(-0600)] <colinclark> Okay, so here's the first question we have to ask ourselves, as framework authors:
[11:03:48 CST(-0600)] <colinclark> a. Which format, if any, is easier and more understandable for our users?
[11:03:58 CST(-0600)] <mlam> In HTML5, we're saying, we are accepting all image file extensions, and the user can't be more specific with image extensions
[11:04:16 CST(-0600)] <colinclark> mlam: We can specify a more specific MIME type though, right?
[11:04:23 CST(-0600)] <colinclark> image/jpeg, for example
[11:04:48 CST(-0600)] <mlam> Yes, sorry, i was referring to the image/* format
[11:05:13 CST(-0600)] <colinclark> So what would it look like to specify only GIF, JPEG, and PNG?
[11:05:17 CST(-0600)] <colinclark> in the HTML format?
[11:05:40 CST(-0600)] <mlam> it would be "image/jpeg,image/png,image/gif"
[11:05:55 CST(-0600)] <colinclark> Ah, okay, cool
[11:06:02 CST(-0600)] <colinclark> so this is really interesting
[11:06:13 CST(-0600)] <mlam> I think the SWFUpload format is the easier format, simply because that's what everyone is used to seeing from most applications
[11:06:41 CST(-0600)] <colinclark> That's interesting
[11:06:53 CST(-0600)] <colinclark> So that's a pro
[11:07:07 CST(-0600)] <colinclark> A con, arguably, is that it appears that SWFUpload is filtering based on file extension rather than MIME type
[11:07:10 CST(-0600)] <mlam> Coming from a FORMER windows user, all office applications filter files out with the *. notation
[11:07:20 CST(-0600)] <mlam> right
[11:07:23 CST(-0600)] <colinclark> meaning, a file that was missing the extensions would not be recognized
[11:07:29 CST(-0600)] <colinclark> which, as a former Windows user, must be odd
[11:07:36 CST(-0600)] <colinclark> but as a current Linux user, must make sense, too
[11:07:57 CST(-0600)] <mlam> yes , and yes
[11:08:10 CST(-0600)] <colinclark> Okay, so as it stands, both formats involve a tokenized String
[11:08:15 CST(-0600)] <mlam> yes
[11:08:38 CST(-0600)] <colinclark> I think, intuitively, I would have picked an array
[11:08:42 CST(-0600)] <colinclark> regardless of what was in it
[11:08:50 CST(-0600)] <colinclark> but I guess packing the array is slightly less convenient
[11:08:53 CST(-0600)] <colinclark> so, it might look like this:
[11:09:08 CST(-0600)] <colinclark> ["image/jpeg", "image/png", "image/gif"]
[11:09:10 CST(-0600)] <mlam> an array would definitely make our lives a bit easier
[11:09:15 CST(-0600)] <colinclark> How come?
[11:09:39 CST(-0600)] <mlam> If it's a tokenized string, we would have to make an extra step to break out the tokens before making any type of conversion
[11:09:42 CST(-0600)] <colinclark> right
[11:09:46 CST(-0600)] <colinclark> That's noteworthy
[11:09:56 CST(-0600)] <colinclark> So, would we argue an array is less convenient for our users, but more so for us?
[11:10:08 CST(-0600)] <colinclark> Or is it actually better for our users, because it makes sense to send along sets of data as an array?
[11:10:09 CST(-0600)] <mlam> I fully agree with the above
[11:10:31 CST(-0600)] <mlam> as in, an array is inconvenient for our uses, but it would benefit us
[11:10:40 CST(-0600)] <colinclark> I'm fully convinced about "more so for us," but still contemplating "less convenient for our users"
[11:11:13 CST(-0600)] <colinclark> yura_: Can I ask you a random question, without you spending much time reading the channel logs above?
[11:11:18 CST(-0600)] <colinclark> in fact, it's better if you don't
[11:11:28 CST(-0600)] <yura_> sure
[11:11:32 CST(-0600)] <colinclark> mlam and I are contemplating the API for file types in Uploader
[11:11:48 CST(-0600)] <colinclark> So, say you want to tell the Uploader only to allow image files, how do you imagine you'd do it?
[11:11:56 CST(-0600)] <colinclark> I give you a fileTypes: property
[11:11:58 CST(-0600)] <colinclark> What do you put in it?
[11:14:34 CST(-0600)] <colinclark> yura_ is probably a bit distracted with CSpace standup
[11:14:59 CST(-0600)] <colinclark> So, mlam just to outline the "API author's process a bit more"...
[11:15:08 CST(-0600)] <mlam> Ok
[11:15:21 CST(-0600)] <colinclark> We can identify some format, be it one of theirs or our own, that makes the most sense for our users.
[11:15:31 CST(-0600)] <colinclark> Then the next thing we'll need to do is ask ourselves a couple of questions...
[11:15:38 CST(-0600)] <colinclark> a. How much change do we have time for?
[11:15:47 CST(-0600)] <colinclark> b. What impact will any change have on our users?
[11:16:02 CST(-0600)] <colinclark> c. In regards to b), can we provide invisible backwards compatibility, were we to change the format
[11:16:12 CST(-0600)] <colinclark> Those are questions we're not quite ready to answer yet, but we're close
[11:16:15 CST(-0600)] <yura_> i m not sure how the type of the file is obtained properly (whether the extension is sufficient enought) but in the list I would be expected to put a list/array of file extensions
[11:16:19 CST(-0600)] <yura_> colinclark: mlam ^
[11:16:23 CST(-0600)] <colinclark> aha
[11:16:25 CST(-0600)] <colinclark> okay
[11:16:27 CST(-0600)] <mlam> interesting
[11:16:42 CST(-0600)] <colinclark> So, that's interesting, though it only tells us yura_'s personal preference
[11:16:48 CST(-0600)] <colinclark> So, I guess we could break it down a tiny bit
[11:16:53 CST(-0600)] <colinclark> File extensions vs. MIME types
[11:17:05 CST(-0600)] <colinclark> I think I'd be willing to argue that MIME types are measurably superior
[11:17:11 CST(-0600)] <yura_> colinclark: yes
[11:17:13 CST(-0600)] <yura_> afreed
[11:17:15 CST(-0600)] <yura_> agreed
[11:17:19 CST(-0600)] <colinclark> Since file extensions provide no definitive way to say "all files of a certain type"
[11:17:49 CST(-0600)] <mlam> but what about SWF's own API? SWFUpload is expecting a tokenized String....so does this mean an array is out of the question?
[11:20:01 CST(-0600)] <mlam> I agree that MIME types would be better. I would have no idea what a ".ogv" extension is at first glance, but I would at least be able to associate that extension as a video type using MIME types
[11:23:23 CST(-0600)] <colinclark> sorry, i was distracted
[11:23:24 CST(-0600)] <colinclark> catching up
[11:23:46 CST(-0600)] <colinclark> mlam: Nothing's out of the question... it just leads us to question a)
[11:23:57 CST(-0600)] <colinclark> So, okay, it seems like we have consensus on MIME types
[11:24:01 CST(-0600)] <colinclark> they're better
[11:24:11 CST(-0600)] <colinclark> and have the capacity to be more succinct
[11:24:26 CST(-0600)] <colinclark> Any -1s for this point?
[11:25:05 CST(-0600)] <colinclark> So far so good, mlam
[11:25:09 CST(-0600)] <mlam>
[11:25:19 CST(-0600)] <colinclark> Okay, so the next question is, "tokenized string vs. array?"
[11:25:47 CST(-0600)] <colinclark> arguably, a tokenized string saves bytes on download (less quotation marks )
[11:26:08 CST(-0600)] <colinclark> but costs more at runtime (parsing the tokens and converting on one platform)
[11:26:34 CST(-0600)] <colinclark> we could avoid most of that second point by simply adopting the <input accepts="..."> format as-is
[11:26:40 CST(-0600)] <mlam> even if we had an array, we would still have to concatenate all the tokens into a tokenized string
[11:26:47 CST(-0600)] <colinclark> Right
[11:27:05 CST(-0600)] <colinclark> which is a runtime cost we'd pay for both implementations (SWFUpload and HTML5)
[11:27:38 CST(-0600)] <colinclark> So, can we think of any other arguments for why a delimited String is a poor idea?
[11:27:46 CST(-0600)] <colinclark> or at least, less optimal?
[11:28:40 CST(-0600)] <colinclark> okay nothing immediate
[11:28:43 CST(-0600)] <mlam> I think I prefer a delimited String. I think it's what most users are used to seeing
[11:28:48 CST(-0600)] <colinclark> Okay
[11:29:04 CST(-0600)] <colinclark> So, postponing a file decision, let's explore some of the consequences of this approach
[11:29:36 CST(-0600)] <colinclark> If we were to adopt the HTML accepts format as-is, what would the code look like?
[11:29:45 CST(-0600)] <colinclark> We wouldn't have to do anything for the HTML5 strategy
[11:29:48 CST(-0600)] <colinclark> it would just work as-is
[11:29:50 CST(-0600)] <mlam> right
[11:29:53 CST(-0600)] <colinclark> okay, cool
[11:30:03 CST(-0600)] <colinclark> So, how would we convert from MIME types to file extensions, mlam?
[11:30:19 CST(-0600)] <colinclark> If I remember correctly the second half of the MIME type isn't a real file extension, right?
[11:30:27 CST(-0600)] <colinclark> like, for example, "image/jpeg"
[11:30:27 CST(-0600)] <mlam> No, it's not
[11:30:29 CST(-0600)] <colinclark> ok
[11:30:46 CST(-0600)] <colinclark> So would we need some kind of map in order to convert from MIME type to file extension?
[11:30:54 CST(-0600)] <mlam> I think we would we need a key/value pairing structure that would match up the formats and make the conversion that way
[11:31:01 CST(-0600)] <mlam> you type too fast
[11:31:12 CST(-0600)] <colinclark>
[11:31:15 CST(-0600)] <colinclark> Hmm
[11:31:24 CST(-0600)] <colinclark> Not ideal, since I imagine it might be pretty large
[11:31:24 CST(-0600)] <mlam> I think the conversion would need to happen with both strategies
[11:31:27 CST(-0600)] <colinclark> why?
[11:31:52 CST(-0600)] <mlam> even though we want users to use mime types, there's no guarantee that they would set the options properly
[11:31:58 CST(-0600)] <colinclark> Hmm
[11:32:10 CST(-0600)] <colinclark> Assuming the options format was properly documented...
[11:32:16 CST(-0600)] <colinclark> wouldn't it be a bug in their code if they set it wrong?
[11:32:21 CST(-0600)] <mlam> yes, it would
[11:32:25 CST(-0600)] <colinclark> Or am I misunderstanding?
[11:33:15 CST(-0600)] <mlam> No, you're not. I guess I'm looking at the perspective of the user. If there are 2 acceptable formats , I can see a user mistakenly insert file types instead of mime types
[11:33:32 CST(-0600)] <colinclark> I guess our point, if we settle on this format, is to say "there is only one format"
[11:33:48 CST(-0600)] <colinclark> It's entirely an implementation detail of the SWFUpload strategy if that format gets converted
[11:33:56 CST(-0600)] <colinclark> It's a lot like how we handle events in the Uploader
[11:33:58 CST(-0600)] <mlam> Oh ok
[11:34:02 CST(-0600)] <colinclark> they all map to real events in SWFUpload
[11:34:11 CST(-0600)] <colinclark> but we chose our own, more user-friendly names
[11:34:29 CST(-0600)] <colinclark> The user has no idea that these get converted somewhere in the guts of the SWFUpload strategy
[11:34:48 CST(-0600)] <colinclark> Okay, so we're stuck in a somewhat non-ideal situation no matter which way we go
[11:35:02 CST(-0600)] <mlam> what about the case for current HTML5 users? they would definitely have to make changes to their implementation when the upgrade to 1.3.1
[11:35:09 CST(-0600)] <mlam> Yah
[11:35:10 CST(-0600)] <colinclark> yes, that's right
[11:35:16 CST(-0600)] <colinclark> We have to hold a map of MIME types vs file extensions, either way
[11:35:38 CST(-0600)] <colinclark> There's no way we could hold a comprehensive list of MIME types and extensions, either
[11:35:41 CST(-0600)] <colinclark> we could certainly try our best
[11:35:48 CST(-0600)] <colinclark> but it's likely something people might need to extend
[11:36:10 CST(-0600)] <colinclark> So, the argument about backwards compatibility is a really good one
[11:36:17 CST(-0600)] <colinclark> let's separate it for a sec and consider it next
[11:36:24 CST(-0600)] <mlam> I found a fairly complete list from the Mozilla site, but I'll have to dig some more to make sure our map is as complete as possible
[11:36:40 CST(-0600)] <colinclark> mlam: I guess it's an open question if we even want a fully complete list
[11:36:57 CST(-0600)] <colinclark> it's a lot to push down to the user's browser, just for a case that may never apply
[11:37:09 CST(-0600)] <colinclark> Okay, so here's what we know so far:
[11:37:10 CST(-0600)] <mlam> Ah, I see
[11:37:15 CST(-0600)] <colinclark> 1. We like MIME types better than file extensions
[11:37:24 CST(-0600)] <colinclark> 2. We're going to have to convert one to the other
[11:37:38 CST(-0600)] <colinclark> 3. In order to convert them, we're going to need to have a map of MIME types to file extensions
[11:37:42 CST(-0600)] <colinclark> Seem about right?
[11:37:47 CST(-0600)] <mlam> yes
[11:38:21 CST(-0600)] <colinclark> Okay, so I think we should store this map in the defaults of the strategy that needs conversion
[11:38:38 CST(-0600)] <colinclark> So, if we go with the HTML5 accepts format, then we should store this map as a configurable option of the SWFUpload strategy
[11:38:55 CST(-0600)] <colinclark> this way, if our list isn't fully comprehensive, an implementor can extend it according to their needs
[11:38:58 CST(-0600)] <mlam> makes sense
[11:39:13 CST(-0600)] <colinclark> but our list should probably at least be "reasonably complete"
[11:39:25 CST(-0600)] <colinclark> Okay, so now the next question
[11:39:33 CST(-0600)] <colinclark> What impact would this approach have on the development time?
[11:39:39 CST(-0600)] <colinclark> In other words, how long would it take you to implement?
[11:40:02 CST(-0600)] <colinclark> Justin_o and jessm and I are probably going to check in about the release schedule after basketball
[11:40:18 CST(-0600)] <mlam> I would think about 2 solid days. But the problem is that I'm on vacation starting thursday
[11:40:26 CST(-0600)] <colinclark> ok
[11:40:32 CST(-0600)] <mlam> I don't mind spending some extra time though
[11:40:35 CST(-0600)] <colinclark> So michelled would probably need to pick it up once you leave
[11:40:45 CST(-0600)] <colinclark> Okay, so the next question...
[11:40:50 CST(-0600)] <colinclark> What impact will this have on our users?
[11:40:59 CST(-0600)] <colinclark> It's not ideal to change an API like this in a point point release
[11:41:05 CST(-0600)] <colinclark> it might cause Justin_o to freak
[11:41:13 CST(-0600)] <colinclark> On the other hand, Uploader is not yet at production status
[11:41:21 CST(-0600)] <colinclark> and this is one of the key bugs to fix in order to get it up there
[11:41:29 CST(-0600)] <colinclark> mlam: Could we provide backwards compatibility somehow?
[11:41:48 CST(-0600)] <colinclark> It seems like it might be challenging... we'd have to parse the option and look to see if it contained something that looks like the old format
[11:41:56 CST(-0600)] <mlam> I'm not really sure.
[11:42:07 CST(-0600)] <colinclark> Another option would be to support both formats and deprecate the file extension property
[11:42:18 CST(-0600)] <colinclark> which raises awkward questions like "what happens if the user gives us both?"
[11:42:57 CST(-0600)] <colinclark> I guess we might be able to look for the presence of asterisks and dots
[11:43:14 CST(-0600)] <colinclark> which uniquely, i think, would identify the old options format
[11:43:43 CST(-0600)] <colinclark> Justin_o: We're coming rather close to breaking API compatibility in a point point release here
[11:43:49 CST(-0600)] <colinclark> any thoughts, generally speaking?
[11:43:52 CST(-0600)] <mlam> I'm not really a fan of supporting both formats...as you mentioned above, we'd be parsing and converting every time the uploader runs.
[11:43:58 CST(-0600)] <colinclark> yes
[11:44:11 CST(-0600)] <colinclark> and it could be confusing for users, potentially
[11:44:17 CST(-0600)] <colinclark> it might be the only responsible thing we can do, though
[11:44:51 CST(-0600)] <mlam> if we support both formats, would introducing an option for mimeType in the queue settings be out of the question?
[11:45:17 CST(-0600)] <mlam> and if/when SWF becomes unsupported , we deprecate the fileTypes option?
[11:57:09 CST(-0600)] <colinclark> mlam: I think we'd probably deprecate the fileTypes option right away
[11:57:33 CST(-0600)] <colinclark> Okay, so I chatted briefly with Justin_o
[11:58:39 CST(-0600)] <colinclark> and he outlined a handful of potential scenarios
[11:58:45 CST(-0600)] <colinclark> let me see if I can articulate them
[11:58:55 CST(-0600)] <colinclark> 1. Just break backwards compatibility and beg forgiveness
[11:59:40 CST(-0600)] <colinclark> 2. Introduce a new option, acceptedMIMETypes or something like that, deprecate fileTypes, and provide bi-directional conversion between MIME types and file extensions
[11:59:46 CST(-0600)] <colinclark> to elaborate, that means:
[11:59:58 CST(-0600)] <colinclark> a) if we get fileTypes, we convert to MIME types for HTML5 and do nothing for Flash
[12:00:15 CST(-0600)] <colinclark> b) if get acceptedMIMETypes, we convert to file extensions for Flash and do nothing for HTML5
[12:00:44 CST(-0600)] <colinclark> c) if we get both, we do nothing in both cases and hand off the most appropriate option to the strategy, leaving it users to ensure that both options match
[12:01:36 CST(-0600)] <colinclark> 3. Change formats from file extensions to MIME types and write some kind of "options chewer" that can detect unique patterns that distinguish the old format from the new. And then transform as appropriate
[12:01:48 CST(-0600)] <colinclark> So both #2 and #3, we'd have to support bi-directional transformations
[12:01:53 CST(-0600)] <colinclark> Which is less ideal in some ways...
[12:02:19 CST(-0600)] <colinclark> I'd really like to hide away this whole MIME type to file extension map in the Flash strategy
[12:02:47 CST(-0600)] <colinclark> so that implementers, if they want to embrace modernity, can just not include the Flash file, and deliver a nice small package to the browser
[12:03:02 CST(-0600)] <colinclark> mlam: Can you think of any other scenarios?
[12:03:09 CST(-0600)] <colinclark> Do all of these make sense?
[12:03:13 CST(-0600)] <colinclark> And do you have a preference?
[12:03:15 CST(-0600)] <mlam> I see. Just reading through all the options again
[12:03:27 CST(-0600)] <colinclark> Think about those questions while you play basketball, and we can make a decision when you get back
[12:05:04 CST(-0600)] <mlam> #1 made me laugh. But I like it I think #2 seems most reasonable.
[12:05:23 CST(-0600)] <mlam> I won't be playing basketball today. So I'll be here
[12:07:20 CST(-0600)] <colinclark> I find #1 frightfully appealing
[12:08:07 CST(-0600)] <mlam> I really do like #1, #2 just seems the most PC.
[12:08:11 CST(-0600)] <colinclark> lol
[12:08:19 CST(-0600)] <colinclark> By PC, you mean "nice?"
[12:08:24 CST(-0600)] <mlam> yes
[12:08:36 CST(-0600)] <colinclark> I think I'm leaning towards #3
[12:09:58 CST(-0600)] <mlam> #1 isn't that bad though considering the uploader isn't a production component yet, r ight?
[12:10:09 CST(-0600)] <colinclark> We might be able to argue that
[12:10:16 CST(-0600)] <colinclark> but this is a feature people do use, I suspect
[12:10:26 CST(-0600)] <mlam> Yes, most likely
[12:10:29 CST(-0600)] <colinclark> and we are issuing a minor maintenance release
[12:10:32 CST(-0600)] <colinclark> which complicates things
[12:10:51 CST(-0600)] <mlam> Hm, do you think this issue is more suitable for 1.4?
[12:12:11 CST(-0600)] <colinclark> I dunno
[12:12:18 CST(-0600)] <colinclark> It seems to me that it's a big bug
[12:12:21 CST(-0600)] <colinclark> we should fix it
[12:12:30 CST(-0600)] <colinclark> so pushing it off to a larger release only defers some of these questions
[12:16:58 CST(-0600)] <mlam> shall we go with option #3 then?
[12:18:26 CST(-0600)] <Bosmon> In your course of moving towards #2 or #3, you could ransack the file "contentTypes.js" which had formerly been a part of Engage/Kettle
[12:19:20 CST(-0600)] <Bosmon> ransack... and extend
[12:28:52 CST(-0600)] <colinclark> Bosmon: Ooh, cool
[12:28:55 CST(-0600)] <colinclark> yes, that's exactly what we need
[12:29:04 CST(-0600)] <colinclark> Do you have any particular opinion on #2 or #3?
[12:30:06 CST(-0600)] <Bosmon> I'm struggling to understand how #3 is different to #2
[12:30:12 CST(-0600)] <Bosmon> What are "formats"?
[12:31:42 CST(-0600)] <colinclark> If you scroll further back in the log, you can see them
[12:31:48 CST(-0600)] <colinclark> mlam provided some examples
[12:32:03 CST(-0600)] <Bosmon> Wow... so much stuff
[12:32:17 CST(-0600)] <colinclark>
[12:32:22 CST(-0600)] <colinclark> brb... sandwich run
[12:34:28 CST(-0600)] <Bosmon> ok
[12:34:30 CST(-0600)] <Bosmon> I am caught up
[12:34:36 CST(-0600)] <Bosmon> "formats" are pernicious
[12:34:40 CST(-0600)] <Bosmon> And should be disused
[12:34:48 CST(-0600)] <Bosmon> Inserting myself into your "API authors chat"
[12:35:17 CST(-0600)] <Bosmon> A cardinal rule should be... "DO NOT INTRODUCE or attempt to parse new kinds of text-based streams of tokens"
[12:35:38 CST(-0600)] <Bosmon> Avoidance of this is the whole reason we choose to program with JSON in the first place
[12:44:01 CST(-0600)] <mlam> so Bosmon, you're preference is option #1?
[12:49:02 CST(-0600)] <Bosmon> #2
[12:49:13 CST(-0600)] <Bosmon> At least as far as I understand it
[12:49:31 CST(-0600)] <Bosmon> I'm still not quite clear which out of #2 and #3 involve the parsing of random string formats
[12:49:33 CST(-0600)] <Bosmon> Possibly both
[12:49:50 CST(-0600)] <Bosmon> But #3 mentions the word "formats"
[12:50:57 CST(-0600)] <mlam> I think both #2 and #3 imply that we would involve parsing string formats
[12:56:47 CST(-0600)] <Bosmon> Ok, then we need to set up #4
[12:56:57 CST(-0600)] <Bosmon> I guess I still don't quite understand the distinction between #2 and #3
[12:58:26 CST(-0600)] <Bosmon> Given a data structure like the one in "contentTypes.js" bidirectional conversion is easy to achieve
[12:58:51 CST(-0600)] <Bosmon> The concept of "auto-detecting" obsolete styles of option by "string-spotting" seems dangerous
[12:59:10 CST(-0600)] <Bosmon> Whatever "options chewing" we do should be done by a system like the one Colin started to put in place for the previous release
[12:59:29 CST(-0600)] <Bosmon> That is, an explicit request from the user or environment to be allowed to issue particularly versions of out-of-date options
[12:59:34 CST(-0600)] <Bosmon> particular
[13:03:59 CST(-0600)] <colinclark> okay, so this is good
[13:04:03 CST(-0600)] <colinclark> We have an option #4
[13:04:29 CST(-0600)] <colinclark> 4. Don't go with a delimited string format at all. File types should be expressed as an array of MIME types.
[13:05:23 CST(-0600)] <colinclark> Backwards compatibility can be detected based on argument type in this case, and we can define a new transformation expander to parse the old string-based format and turn it into the array of MIME types
[13:05:41 CST(-0600)] <colinclark> Bosmon: Is that about right?
[13:09:34 CST(-0600)] <Bosmon> colinclark: Yes, that sounds about right
[13:09:45 CST(-0600)] <Bosmon> Delimited formats are an awful integrity risk
[13:10:23 CST(-0600)] <Bosmon> You never know when someone is going to come along with some awful syntactic hole in your "grammar" and escaping
[13:10:39 CST(-0600)] <Bosmon> Our single example of a non-JSON grammar (our "EL language") is a bad enough risk as it is
[13:20:53 CST(-0600)] <mlam> colinclark: if i destroy my fork on github, will the pull request automatically be cancelled?
[13:21:16 CST(-0600)] <colinclark> I don't know
[13:21:19 CST(-0600)] <colinclark> maybe Justin_o knows
[13:21:26 CST(-0600)] <colinclark> So, mlam, what do you think about #4?
[13:21:53 CST(-0600)] <mlam> Seems like the cleanest approach programmatically, that's for sure
[13:21:58 CST(-0600)] <colinclark> We sort of skimmed it earlier in our conversation
[13:22:10 CST(-0600)] <mlam> yes
[13:22:31 CST(-0600)] <colinclark> So you think it's a good approach? Or do you prefer one of the others?
[13:23:45 CST(-0600)] <mlam> I do like the approach. But as we mentioned earlier, it comes as a cost to the integrator. If we don't go with this approach, it comes at a runtime cost.
[13:24:08 CST(-0600)] <Bosmon> Well - is it any more of a cost to the integrator than #2 or #3? They would face a "change" in either case
[13:26:34 CST(-0600)] <colinclark> I guess the cost is arguably a very slight performance one... for the HTML5 strategy, we'll have to run .join() on the array of MIME types before sticking it in the DOM
[13:26:37 CST(-0600)] <Bosmon> And given they face a change, I don't see it's "much skin off their nose" to write a JSON structure, which is only very slightly more verbose than a delimited string
[13:26:40 CST(-0600)] <colinclark> pretty trivial, I think
[13:27:05 CST(-0600)] <mlam> Right. a change will happen regardless. I guess the API wouldn't change with #2 or #3. But if an API change is acceptable here, then I definitely like option #4
[13:27:07 CST(-0600)] <Bosmon> It's one of the "miracles of JSON" that it is very rarely much longer than the "shortest sensible structure you could write"
[13:27:27 CST(-0600)] <colinclark> Okay, well, I feel fairly good about this
[13:27:41 CST(-0600)] <colinclark> michelled: Were you able to catch up? What do you think about the various scenarios?
[13:27:46 CST(-0600)] <Bosmon> mlam - I think even that issue is "suspicious" - there are lots of ways of arguing you have "not made an API change" from what one might call a "Java-theoretic perpective"
[13:27:56 CST(-0600)] <Bosmon> That is, "none of the names, types or signatures have changed"
[13:27:56 CST(-0600)] <colinclark> lol
[13:28:12 CST(-0600)] <colinclark> Yes, we were chatting earlier about how shady most of these "we're not making a change" arguments end up being
[13:28:24 CST(-0600)] <colinclark> Justin_o had some especially devious arguments
[13:28:33 CST(-0600)] <Bosmon> But anything you do which causes a failure if "people carry on doing what they have done before" in the widest moral sense has to count as an "API change"
[13:28:43 CST(-0600)] <Bosmon> This is what I discovered in the JSF/Hibernate days, for example
[13:28:57 CST(-0600)] <Bosmon> The field was dominated by people who slimed their way out of API issues by claiming that there was no API change
[13:29:07 CST(-0600)] <Bosmon> Their stuff failed to work, all the same
[13:31:01 CST(-0600)] <Bosmon> This is actually YET ANOTHER argument for why JSON is great.... it allows you to "see into arguments" that are specified as part of your API that would otherwise be opaque
[13:31:26 CST(-0600)] <Bosmon> From a Java standpoint, all you could say is "this is a function which accepts a String"
[13:31:33 CST(-0600)] <Bosmon> But.... what KIND of String, gentlemen?
[13:31:40 CST(-0600)] <colinclark> lol
[13:31:47 CST(-0600)] <colinclark> Indeed
[13:31:51 CST(-0600)] <Bosmon> Are you going to produce a BNF grammar for this String, "Sir"?
[13:31:53 CST(-0600)] <mlam> haha
[13:32:34 CST(-0600)] <Bosmon> Perhaps you would care to check whether this grammar has any ambiguities or "shift-reduce conflicts"
[13:34:04 CST(-0600)] <colinclark> I michelled is busy at the moment, but I'd say go for it, mlam
[13:34:08 CST(-0600)] <Bosmon> More realistically it would be some kind of loosely-defined thing you promise to hack at with a few RegExps and assert that "this hasn't cause any problems in practice recently"
[13:34:12 CST(-0600)] <colinclark> I really enjoyed talking through it here with you!
[13:34:20 CST(-0600)] <Bosmon> Anyway, sorry to bang on about this
[13:34:40 CST(-0600)] <Bosmon> I was just reading though how most of the IDEs actually treat Javascript in that way when they give you syntax assistance
[13:34:47 CST(-0600)] <mlam> Ok, cool. Definitely a good discussion
[13:35:11 CST(-0600)] <Bosmon> That actually they have no really sound ability to assert that what is in the buffer is a syntactically valid Javascript program at all
[13:35:19 CST(-0600)] <Bosmon> That is, until we got jslint....
[13:38:15 CST(-0600)] <michelled> sorry for disappearing like that - I agree with option #4
[13:38:31 CST(-0600)] <michelled> it was great to be able to read the whole conversation and understand where the decision came from!
[13:39:43 CST(-0600)] <michelled> mlam: let me know how it goes and call me over if you feel like a pair
[13:40:17 CST(-0600)] <mlam> Ok, I will. I'm just trying to finish up another patch before I get started on this
[13:41:45 CST(-0600)] <colinclark> michelled: I suggested to mlam that, since he's heading off on vacation on Thursday, he should square away any other patches before picking this one back up
[13:41:59 CST(-0600)] <colinclark> and that you might be able to keep it going once he heads off to Mexico
[13:43:40 CST(-0600)] <mlam> colinclark: how did you create a remote branch within your fork on github?
[13:44:04 CST(-0600)] <colinclark> Can you elaborate on what you want to do, mlam?
[13:44:58 CST(-0600)] <mlam> I wanted to start from scratch on github so that i can better organize my branches. I've just forked infusion trunk and now i want to create a remote branch to move some code changes into it
[13:45:10 CST(-0600)] <colinclark> Okay
[13:45:22 CST(-0600)] <colinclark> Clone your fork onto your local machine
[13:45:37 CST(-0600)] <mlam> Ok
[13:45:42 CST(-0600)] <colinclark> If you want to create a new branch, you should be able to just run "git branch add <name>"
[13:45:49 CST(-0600)] <colinclark> typically we're naming the branch after the JIRA number
[13:46:01 CST(-0600)] <colinclark> I think "git checkout -b <name>" will do the same thing
[13:46:03 CST(-0600)] <Bosmon> I love the way Canadians speak "proper English"
[13:46:05 CST(-0600)] <colinclark> but only Justin_o knows for sure
[13:46:25 CST(-0600)] <mlam> colinclark: that's just a local branch though, right?
[13:46:38 CST(-0600)] <colinclark> Yes, but then you can push the branch back up to "origin"
[13:46:45 CST(-0600)] <colinclark> (which is your fork)
[13:48:08 CST(-0600)] <mlam> I'm looking at your repo right now on github, and you have an "infusion-FLUID-4037" fork and within that fork, you have a branch of FLUID-4037
[13:48:39 CST(-0600)] <colinclark> yes, that's right
[13:48:53 CST(-0600)] <mlam> by pushing my local repo back into the origin wouldn't create a branch equivalent to the FLUID-4037 remote branch
[13:49:16 CST(-0600)] <mlam> I would just be pushing back into my remote master, right?
[13:49:23 CST(-0600)] <colinclark> It depends what you push back