fluid-work IRC Logs-2011-03-01

[07:50:54 CST(-0600)] <anastasiac> Justin_o, good morning. I have a github question/problem
[07:51:13 CST(-0600)] <Justin_o> hi anastasiac sure
[07:51:53 CST(-0600)] <anastasiac> I tested downloading the zip/tarball of the latest master, and the resulting filename includes the 1.3.1 version number. I can't tell where github is getting that number from
[07:52:10 CST(-0600)] <anastasiac> the download was of master, and so should have 1.4-SNAPSHOT
[07:56:18 CST(-0600)] <Justin_o> anastasiac: hmm.. good question
[07:56:29 CST(-0600)] <Justin_o> maybe it grabs the latest tag name.. or something from one of the properties files
[07:56:31 CST(-0600)] <Justin_o> or pom
[07:56:45 CST(-0600)] <Justin_o> i'll give it a try to and see what happens
[07:56:47 CST(-0600)] <anastasiac> but you've updated the properties and pom files
[07:56:51 CST(-0600)] <Justin_o> maybe i'll make a new fork and play with it a bit
[07:56:59 CST(-0600)] <Justin_o> anastasiac: hmm.. good point about that
[08:04:13 CST(-0600)] <Justin_o> anastasiac: so i'm definitely seeing what you're seeing.. it also seems to include, at least a portion, of the commit hash
[08:04:21 CST(-0600)] <Justin_o> i'll see if i can do some testing on this
[08:04:47 CST(-0600)] <anastasiac> yeah, I don't mind the commit hash - downloading from master that makes sense. but the wrong version number seems to be a problem, Justin_
[08:09:58 CST(-0600)] <Justin_o> anastasiac: i think i figured it out
[08:10:12 CST(-0600)] <anastasiac> I knew you would
[08:10:17 CST(-0600)] <Justin_o> take a look at my test repo
[08:10:17 CST(-0600)] <Justin_o> https://github.com/jobara/infusion-test
[08:10:46 CST(-0600)] <anastasiac> what am I looking for, Justin_o?
[08:11:13 CST(-0600)] <anastasiac> ah, it uses the most recent tag
[08:11:22 CST(-0600)] <anastasiac> well, that just seems wrong
[08:11:31 CST(-0600)] <Justin_o> anastasiac: yes.. that's what it is..
[08:11:41 CST(-0600)] <Justin_o> i think there may also be something with the number that appears right after
[08:12:05 CST(-0600)] <anastasiac> that's not a commit hash, is it?
[08:13:37 CST(-0600)] <anastasiac> well, I'm not sure there's anything we can do about that, even if it does seem wrong, Justin_o. github creates that filename, we don't have any control over it
[08:13:43 CST(-0600)] <anastasiac> it just seems a bit misleading
[08:13:51 CST(-0600)] <anastasiac> you're not downloading 1.3.1
[08:13:57 CST(-0600)] <Justin_o> anastasiac: yes.. that is true
[08:14:00 CST(-0600)] <anastasiac> you're downloading master, which is past 1.3.1
[08:14:13 CST(-0600)] <Justin_o> i'm wondering if the number after is some indication of how long you are past the tag
[08:14:20 CST(-0600)] <anastasiac> that's what I'm guessing
[08:18:20 CST(-0600)] <Justin_o> although in my test i'm only about five commits off of head
[08:18:26 CST(-0600)] <Justin_o> but the number is 7
[08:18:30 CST(-0600)] <Justin_o> so i'm not too sure
[08:24:07 CST(-0600)] <anastasiac> Justin_o, as a point of interest: if you unpack your downloaded bundle, the resulting folder name includes the latest commit hash
[08:25:27 CST(-0600)] <Justin_o> yes.. i think i noticed that, with no tag name. is that what you saw?
[08:26:23 CST(-0600)] <Justin_o> anastasiac: also i just pushed another commit to my test repo and the number after the tag incremented by 1
[08:26:41 CST(-0600)] <Justin_o> so i think it is the number of changes since tag
[08:26:44 CST(-0600)] <anastasiac> ok, so maybe your "about five commits" was actually 7
[08:26:50 CST(-0600)] <Justin_o> anastasiac: could be
[08:29:07 CST(-0600)] <Justin_o> anastasiac: well if you look at the graph
[08:29:08 CST(-0600)] <Justin_o> https://github.com/jobara/infusion-test/network
[08:29:26 CST(-0600)] <Justin_o> the one i tagged is the last one on the pink line
[08:29:34 CST(-0600)] <Justin_o> so it is only 5 commits from the head
[08:29:44 CST(-0600)] <Justin_o> maybe it has something to do with the branch merging though
[08:30:18 CST(-0600)] <anastasiac> hm
[08:31:33 CST(-0600)] <anastasiac> Justin_o, michelled, jessm: I've further updated the README based on Justin_o's comments yesterday. I'd appreciate more feedback. You can see the README in my github branch, at https://github.com/acheetham/infusion/tree/FLUID-4120.
[08:46:22 CST(-0600)] <jessm> anastasiac: i'll take a peak in a moment
[08:46:38 CST(-0600)] <anastasiac> jessm, thanks - no rush, just FYI
[08:52:05 CST(-0600)] <Justin_o> anastasiac: okay did some more testing and yes, it looks like the number after the tag name has something to do with the number of changes.. and i think that number is increased by merges
[08:52:15 CST(-0600)] <Justin_o> like merges cause a change of 2 instead of 1
[08:52:18 CST(-0600)] <Justin_o> or something like that
[08:52:24 CST(-0600)] <anastasiac> interesting
[09:06:13 CST(-0600)] <jessm> anastasiac: half a page of ways to download! michelled and i talked about that yesterday and about the grand plan to simplify
[09:06:40 CST(-0600)] <anastasiac> yes, indeed! If I've overdone it, please let me know
[09:06:41 CST(-0600)] <jessm> anastasiac: it looks good to me – i'm excited about where it's all going
[09:07:03 CST(-0600)] <jessm> anastasiac: it should probably be somewhere, so until we simplify it further, it seems fine
[09:07:07 CST(-0600)] <jessm> michelled: you agree? ^
[09:26:37 CST(-0600)] <anastasiac> michelled, I've reworked the release process main page. When you have a minute, could you have a look and see if it's what you were thinking? The subpages themselves still need cleaning up (so don't look too closely at them) but let me know if this is the breakdown you were thinking of.
[09:26:38 CST(-0600)] <anastasiac> http://wiki.fluidproject.org/display/fluid/Draft+Updated+Release+Process
[09:28:47 CST(-0600)] <colinclark> anastasiac, jessm: Justin_o, michelled and I are just talking through the big picture of builds, downloads, and the like...
[09:28:50 CST(-0600)] <colinclark> We're making a wiki page
[09:28:56 CST(-0600)] <colinclark> and we'll summarize here in the channel in a sec
[09:28:58 CST(-0600)] <colinclark> sorry for the delay
[09:29:12 CST(-0600)] <anastasiac> np
[09:43:26 CST(-0600)] <harriswong> heidi_: I am getting that "gap" you were talking about before, on the 'browse files' button.
[09:43:55 CST(-0600)] <heidi_> harriswong ah yes, we had figured out the issue. the demo wasn't including and fss stylesheet that uploader itself does. it's in jira
[09:44:08 CST(-0600)] <harriswong> heidi_: ok
[09:48:41 CST(-0600)] <anastasiac> jamon, colinclark, jessm, wiki seems to be working now
[09:49:53 CST(-0600)] <jamon> just a few more hours now anastasiac and it will be shiny new
[09:50:01 CST(-0600)] <anastasiac> looking forward to it!
[09:50:13 CST(-0600)] <jamon> me too..
[10:08:53 CST(-0600)] <michelled> anastasiac: I like the new structure for the release process
[10:09:11 CST(-0600)] <michelled> anastasiac: let me know when I should look at the sub pages in detail
[10:09:28 CST(-0600)] <anastasiac> thanks, michelled, will do
[10:09:40 CST(-0600)] <michelled> at a quick glance, I think that the documentation JIRAs should be part of planning the release
[10:10:43 CST(-0600)] <michelled> anastasiac: you can delete the Release Start page I created
[10:11:04 CST(-0600)] <anastasiac> yes, I've moved the text there into the Planning page already
[10:11:57 CST(-0600)] <anastasiac> as to docs jiras, I'm not quite sure: they involve reviewing the docs for accuracy, and you can't really do that until after the open coding phase is over at the very least
[10:12:18 CST(-0600)] <anastasiac> but i'm open to being convinced otherwise, michelled
[10:16:21 CST(-0600)] <michelled> anastasiac: I think creating the JIRA issues should be done early on. there is documentation that can be worked on throughout the release cycle
[10:16:31 CST(-0600)] <michelled> actually closing them will have to wait until code freeze
[10:23:17 CST(-0600)] <anastasiac> good point, will do
[10:56:50 CST(-0600)] <colinclark> anastasiac, jessm: Here's the wiki page with notes from my chat with Justin_o and michelled about the future of builds:
[10:56:52 CST(-0600)] <colinclark> http://wiki.fluidproject.org/display/fluid/Infusion+Build+Scripts+Roadmap
[10:57:04 CST(-0600)] <colinclark> I think we have a few underlying goals as a community
[10:57:26 CST(-0600)] <colinclark> 1. Make it easy to get Infusion: users should have the option of either using the Builder or grabbing a source code release from Github
[10:58:25 CST(-0600)] <colinclark> That means no more standalone source bundles--users will be directed straight to the Builder if they want to download
[10:59:02 CST(-0600)] <colinclark> 2. From a technical perspective, we want more symmetry between the file system layout of our source code repository and our build products
[10:59:03 CST(-0600)] <Justin_o> colinclark: how should we go about deprecating the war file
[10:59:12 CST(-0600)] <Justin_o> just a note in the README ?
[10:59:13 CST(-0600)] <colinclark> That means deprecating the war file, as Justin_o says
[10:59:16 CST(-0600)] <colinclark> Justin_o: Yep, I think so
[10:59:27 CST(-0600)] <Justin_o> colinclark: thanks
[10:59:39 CST(-0600)] <Justin_o> anastasiac: could you add that to the README.txt as you are updating it now
[10:59:40 CST(-0600)] <Justin_o> ?
[10:59:59 CST(-0600)] <colinclark> 3. Make our production builds really, really streamlined and our development builds useful and rich, but not too much so
[11:00:29 CST(-0600)] <colinclark> That means an absolute bare minimum of files in the production build--only a concatenated, minified MyInfusion.js and the HTML templates, CSS, and images associated with components and the FSS
[11:00:33 CST(-0600)] <anastasiac> I'll do that
[11:00:36 CST(-0600)] <colinclark> No individual JS files, etc.
[11:00:46 CST(-0600)] <colinclark> The one wrinkle for development builds is demos
[11:00:56 CST(-0600)] <colinclark> The demo portal is totally hard-baked at the moment
[11:00:58 CST(-0600)] <Justin_o> anastasiac: thanks
[11:00:59 CST(-0600)] <colinclark> it's a monolith
[11:01:32 CST(-0600)] <colinclark> so if users can make a custom development build that contains demos, we're going to need a more flexible, data-driven demo portal
[11:02:24 CST(-0600)] <colinclark> anastasiac: I have some specific ideas about the README. Is now a good time to raise them?
[11:02:41 CST(-0600)] <anastasiac> colinclark, certainly, please!
[11:02:59 CST(-0600)] <colinclark> 1. I think we should highlight the Builder as the first place people are directed to in order to download Infusion
[11:03:06 CST(-0600)] <anastasiac> check
[11:03:08 CST(-0600)] <colinclark> currently it's buried underneath the zillion download links
[11:03:46 CST(-0600)] <colinclark> 2. I don't see any compelling reason to teach people how to download a zip file of the latest development version from Github. We can safely assume that either they want a stable release or they know how to clone the repo
[11:04:00 CST(-0600)] <colinclark> I'm curious what other people think about #2
[11:04:01 CST(-0600)] <anastasiac> actually, the builder is linked right up at the top of the readme
[11:04:38 CST(-0600)] <anastasiac> but removing github download links would clean it up a lot
[11:04:45 CST(-0600)] <colinclark> I guess my point is that it should be at the top of the Download section
[11:05:11 CST(-0600)] <colinclark> I wonder even if there's any point in showing people how to download a zip file from Github for a release tag, at least until the Roadmap I pasted in has been realized
[11:05:11 CST(-0600)] <anastasiac> put "build your own" ahead of getting a bundle... gotcha
[11:05:18 CST(-0600)] <bsparks> I agree with #2 if you go to Github you prolly know how to download or fork
[11:05:20 CST(-0600)] <Justin_o> colinclark: i wonder if we'll want a "Fork on Github" banner on the site or the builder?
[11:05:36 CST(-0600)] <colinclark> bsparks: Cool, thanks
[11:05:37 CST(-0600)] <anastasiac> I wasn't sure about the github bundle releases. Justin_o suggested I add that
[11:05:39 CST(-0600)] <colinclark> Justin_o: That's a good idea
[11:07:08 CST(-0600)] <colinclark> 3. I don't think we need to include the structure of the source code tree in our README anymore. Thinking through it, I can't figure out any reason why we've ever done so
[11:07:08 CST(-0600)] <Justin_o> anastasiac: i can't seem to remember why i suggested that
[11:07:14 CST(-0600)] <anastasiac>
[11:07:44 CST(-0600)] <colinclark> anastasiac: #3 will hopefully bring the Demo Portal section above the fold--it's important information and should be prominent
[11:08:10 CST(-0600)] <anastasiac> k
[11:08:32 CST(-0600)] <colinclark> 3b. Similarly, I'm not sure why we have the directory layout for "other examples and sample code"
[11:08:39 CST(-0600)] <anastasiac> agreed
[11:08:46 CST(-0600)] <colinclark> That's it.
[11:09:05 CST(-0600)] <Justin_o> anastasiac: i think i misunderstood your question the other day
[11:09:08 CST(-0600)] <anastasiac> excellent - these are great ideas, they'll simplify and clarify the file a lot, thanks
[11:09:16 CST(-0600)] <anastasiac> Justin_o, which question?
[11:09:18 CST(-0600)] <Justin_o> so yes.. i think we don't need to link directly to the bundles in the readme
[11:09:24 CST(-0600)] <colinclark> I guess I have one other question, anastasiac
[11:09:30 CST(-0600)] <colinclark> And jessm may have some perspective on this, too
[11:09:38 CST(-0600)] <Justin_o> i think you are were just asking about linking to the tag, but i thought you meant the bundle
[11:09:58 CST(-0600)] <colinclark> Does it seem weird, in a file that is ostensibly the release notes for 1.3.1, to have a section about the next release?
[11:10:05 CST(-0600)] <anastasiac> this morning, yes, Justin_o, I was referring to a bundle of the master
[11:10:23 CST(-0600)] <Justin_o> anastasiac: different, but i think i'm still confused so don't worry
[11:10:25 CST(-0600)] <colinclark> I guess what I might be getting at is the possibility of splitting up the README into two files: the main README and a Release Notes file
[11:10:30 CST(-0600)] <colinclark> I dunno
[11:11:16 CST(-0600)] <anastasiac> colinclark, these edits to the readme were specifically intended to address the fact that the readme is figured prominently on github, and should reflect the current activities, and not the most recent release.
[11:11:28 CST(-0600)] <anastasiac> there were discussions in the channel about it yesterday
[11:12:04 CST(-0600)] <anastasiac> I agree that creating a Release Notes would be a good idea
[11:12:11 CST(-0600)] <anastasiac> another simplification of the readme
[11:12:28 CST(-0600)] <abledaccess> Colin: from yesterday when I used the word "confused" to describe my experience with the wiki, that probably wasn't the wisest choice of words. "Clear" would have been much better.
[11:13:11 CST(-0600)] <colinclark> abledaccess: The wiki is confused. I thought it was a good word
[11:13:15 CST(-0600)] <anastasiac> jessm, thoughts on separating out the current content of the Readme into a readme and a "release notes?"
[11:13:28 CST(-0600)] <colinclark> anastasiac: So, I guess we can step back a bit
[11:13:31 CST(-0600)] <anastasiac> +1 for "confused"
[11:13:43 CST(-0600)] <colinclark> If we were creating a front page for our Github repo, what kind of stuff would it include?
[11:13:48 CST(-0600)] <colinclark> Off the top of my head, I imagine:
[11:13:51 CST(-0600)] <colinclark> 1. What is Infusion?
[11:13:54 CST(-0600)] <colinclark> 2. Why is it cool?
[11:13:58 CST(-0600)] <colinclark> 3. Where do I go download it?
[11:14:01 CST(-0600)] <colinclark> 4. Where are the demos?
[11:14:05 CST(-0600)] <colinclark> 5. How do I get involved?
[11:14:12 CST(-0600)] <colinclark> 6. Who makes Infusion? Who uses Infusion?
[11:14:26 CST(-0600)] <colinclark> Some of this information is in the README, but not a lot of it
[11:14:30 CST(-0600)] <anastasiac> so basically a short version of the website?
[11:14:39 CST(-0600)] <colinclark> Something like that, yes
[11:14:47 CST(-0600)] <anastasiac> no, you're right, the current readme really is a "release notes"
[11:14:52 CST(-0600)] <colinclark> Whereas a Release Notes page includes the sort of stuff currently in our README...
[11:14:58 CST(-0600)] <colinclark> a. What's new?
[11:15:03 CST(-0600)] <colinclark> b. Where do I go get it?
[11:15:09 CST(-0600)] <colinclark> c. What are the known issues?
[11:15:10 CST(-0600)] <colinclark> etc
[11:15:35 CST(-0600)] <anastasiac> exactly
[11:15:53 CST(-0600)] <Justin_o> colinclark: what would it look like during development
[11:16:00 CST(-0600)] <Justin_o> the release notes that is
[11:16:04 CST(-0600)] <colinclark> Ah...
[11:16:08 CST(-0600)] <colinclark> I guess it would look however it looks
[11:16:22 CST(-0600)] <colinclark> Put less flippantly I think it would be updated whenever we most need to update it
[11:16:29 CST(-0600)] <colinclark> might be early in the dev cycle, and then constantly updated
[11:16:31 CST(-0600)] <colinclark> that would be ideal
[11:16:35 CST(-0600)] <colinclark> or it might be just be like it is now
[11:16:39 CST(-0600)] <colinclark> updated at the end, after freeze
[11:16:55 CST(-0600)] <colinclark> The cost of it being out of date is lower if the README page is more tuned towards the general state of affairs
[11:17:16 CST(-0600)] <colinclark> I guess the thing I was missing from my README list is 7. What are our goals and plans for the next release?
[11:17:22 CST(-0600)] <colinclark> not in any particular order, of course
[11:17:44 CST(-0600)] <Justin_o> colinclark: i'm wondering if it will be confusing to people to have it out of date, maybe we don't need it between releases.. only with the release
[11:18:13 CST(-0600)] <jessm> colinclark: any chance we can do a text scrape of something to generate the text for the github page to showcase what Infusion is, etc.?
[11:18:20 CST(-0600)] <jessm> i'm thinking of not duplicating manual entry here
[11:18:33 CST(-0600)] <jessm> and spring cleaning simplifying where possible
[11:18:51 CST(-0600)] <colinclark> jessm: I knew that would be your interest
[11:18:53 CST(-0600)] <colinclark> and it makes sense
[11:19:14 CST(-0600)] <colinclark> so you're saying, if we have a repository of useful text about Infusion, we won't have to worry about constant rewriting
[11:19:19 CST(-0600)] <colinclark> just strategic cut and paste and linking
[11:19:35 CST(-0600)] <colinclark> For the record, I am only advocating cutting and pasting English text
[11:19:43 CST(-0600)] <colinclark> since the language lacks a viable reuse model
[11:19:45 CST(-0600)] <colinclark>
[11:20:12 CST(-0600)] <colinclark> Other than maybe saying "like we just said..."
[11:24:53 CST(-0600)] <jessm> colinclark: i'm becoming a huge fan of intentional redundancy – and i'm calling it consistency
[11:25:05 CST(-0600)] <colinclark>
[11:25:11 CST(-0600)] <colinclark> Seems pretty sensible to me
[11:25:23 CST(-0600)] <jessm> i'm thinking it will be one of the few ways we'll be able to help people keep track of where they are in webspace adn what they're doing
[11:25:25 CST(-0600)] <colinclark> +1 for redundancy... erm... consistency
[11:25:33 CST(-0600)] <jessm>
[11:25:36 CST(-0600)] <colinclark> jessm: Seriously, though, it makes total sense
[11:25:42 CST(-0600)] <colinclark> People are going to come to us from all over the place
[11:25:44 CST(-0600)] <colinclark> this is the Web after all
[11:25:48 CST(-0600)] <jessm> it is!
[11:25:56 CST(-0600)] <colinclark> they're going to find us for the first time through Github, for example
[11:25:59 CST(-0600)] <jessm> and i've no idea how many will come in through github
[11:26:00 CST(-0600)] <jessm> yes
[11:26:01 CST(-0600)] <colinclark> not necessarily through our web site
[11:26:03 CST(-0600)] <jessm> yes
[11:26:10 CST(-0600)] <colinclark> so if there's a consistency across all our stuff
[11:26:12 CST(-0600)] <colinclark> 1. Github
[11:26:13 CST(-0600)] <colinclark> 2. Web site
[11:26:14 CST(-0600)] <colinclark> 3. Builder
[11:26:19 CST(-0600)] <colinclark> 4. Demo portal
[11:26:24 CST(-0600)] <colinclark> users win
[11:26:27 CST(-0600)] <jessm> indeed
[11:26:35 CST(-0600)] <jessm> premeditated redundancy
[11:26:35 CST(-0600)] <colinclark> and we win
[11:26:44 CST(-0600)] <colinclark> since we spend less time explaining things we thought we already explained
[11:26:47 CST(-0600)] <jessm> that's what i'm hoping folks will think about at our web mtg. at 3
[11:26:51 CST(-0600)] <colinclark> much better than "like we said..."
[11:26:57 CST(-0600)] <jessm> and we don't ask users to read and then read more
[11:27:03 CST(-0600)] <jessm> read once, get clarity, do what you want
[11:27:10 CST(-0600)] <colinclark> jessm: So, if we were to try to actually do something here...
[11:27:18 CST(-0600)] <colinclark> are you supportive of the idea of a separate README and release notes?
[11:27:25 CST(-0600)] <colinclark> Justin_o and anastasiac: How about you guys?
[11:27:31 CST(-0600)] <jessm> devil, meet details
[11:27:34 CST(-0600)] <Justin_o> colinclark, jessm : here is the traffic graph from github
[11:27:35 CST(-0600)] <Justin_o> https://github.com/fluid-project/infusion/graphs/traffic
[11:27:56 CST(-0600)] <anastasiac> +2 for separate readme and release notes
[11:27:57 CST(-0600)] <jessm> the issue as i understand it is that the page you come to on the proj. isn't the latest release page, it's the "formerly-known-as-trunk" page
[11:28:11 CST(-0600)] <anastasiac> +1 for consistency of language, text, info, etc
[11:28:11 CST(-0600)] <Justin_o> i'm +1 for the seperation of readme and release
[11:28:34 CST(-0600)] <anastasiac> the problem with redundancy is the maintenance overhead
[11:28:38 CST(-0600)] <colinclark> jessm: Yep, the issue is that when you hit the Infusion repo on Github, you see the release notes for an old release
[11:28:45 CST(-0600)] <jessm> yep
[11:28:49 CST(-0600)] <colinclark> You don't get the context--what is Infusion, where are we going, how can you help?
[11:29:11 CST(-0600)] <jessm> so, let's put the most solid text there that keeps it pithy and gets folks where they want to go, to what they want to do
[11:29:27 CST(-0600)] <colinclark> okay
[11:29:36 CST(-0600)] <jessm> i'm not sure that's the roadmap – as michelled asked me earlier this week – that's not solid ground – i think the infusion page is more solid, but way wordy
[11:29:43 CST(-0600)] <colinclark> yes
[11:29:49 CST(-0600)] <colinclark> succinct and to the point
[11:29:55 CST(-0600)] <jessm> we're a chatty bunch
[11:30:00 CST(-0600)] <colinclark> anastasiac: Does that give you enough to take a stab a second draft, with a separate README and Release Notes?
[11:30:06 CST(-0600)] <colinclark> jessm: Blame colinclark
[11:30:09 CST(-0600)] <anastasiac> absolutely - this is great
[11:30:18 CST(-0600)] <colinclark> blah blah blah blah
[11:30:31 CST(-0600)] <anastasiac> colinclark, channel that energy to the docs
[11:30:41 CST(-0600)] <colinclark> anastasiac:
[11:31:18 CST(-0600)] <jessm> colinclark: when i looked at the infusion page last week, with my spring cleaning gloves on, i was hard pressed to strip text – we're going to have to pick carefully at that one
[11:31:27 CST(-0600)] <colinclark> yes
[11:31:30 CST(-0600)] <colinclark> I think we can do it
[11:31:36 CST(-0600)] <colinclark> I'd be happy to help
[11:31:38 CST(-0600)] <jessm> it's the slippery slope to "who are we" and "what do we do"
[11:31:47 CST(-0600)] <colinclark> yes
[11:32:03 CST(-0600)] <colinclark> fortunately we don't have an identity crisis
[11:32:06 CST(-0600)] <colinclark> just a verbiage crisis
[11:32:15 CST(-0600)] <jessm> yes
[12:23:26 CST(-0600)] <golam> michelled: I will push in changes for inline edit soon so you can take a look. I will get back to you.
[12:23:50 CST(-0600)] <michelled> ok, thanks golam
[12:27:12 CST(-0600)] <abledaccess> Heidi: (from yesterday) Brilliant tip! Look at the css, dummy. I might just get it now...
[12:42:23 CST(-0600)] <colinclark> abledaccess: I found the fluidengage.org site a fairly decent "view source" learning tool. It's got some rough edges, but also some nice examples.
[12:44:10 CST(-0600)] <abledaccess> Colin: I'll check it out. Thanks...
[13:43:23 CST(-0600)] <jhung> The wiki is back up.
[13:48:29 CST(-0600)] <Justin_o> fluid-everyone: i'm wondering if we should add the jslint comment at the top of our js files. It will tell jslint which options to run with
[13:48:32 CST(-0600)] <Justin_o> here's an example
[13:48:45 CST(-0600)] <Justin_o> "/*jslint white: true, undef: true, newcap: true, nomen: true, regexp: true, bitwise: true, browser: true, maxerr: 50, indent: 4 */"
[13:48:51 CST(-0600)] <Justin_o> any thoughts
[13:49:41 CST(-0600)] <michelled> Justin_o: then do we run lint from the command line?
[13:49:46 CST(-0600)] <michelled> or still through the UI?
[13:50:05 CST(-0600)] <Justin_o> michelled: still through the ui, but we won't have to set the checkboxes
[13:50:35 CST(-0600)] <jamon> fluid-everyone: well, wiki is up, though being hit by msn and yahoo at the moment
[13:51:10 CST(-0600)] <colinclark> Justin_o, michelled: It would also allow us to run it more effectively from the command line if we wanted
[13:51:20 CST(-0600)] <colinclark> a lint post-commit hook or something comparable
[13:51:23 CST(-0600)] <jamon> performance increase seems.. negligible, though stability should at least be improved
[13:51:23 CST(-0600)] <colinclark> Nightly Lint Reports
[13:51:29 CST(-0600)] <michelled> Justin_o: it sounds like a good idea to me. the only issue I see is if we want to change those options in the future we'll need to change them in all the files
[13:51:38 CST(-0600)] <michelled> but I think that's probably a good thing
[13:51:50 CST(-0600)] <michelled> instead of what we have now where different people run lint with different settings
[13:55:08 CST(-0600)] <jhung> fluid-everyone: we're planning on meeting to chat about Infusion web and documentation at 3pm ET.
[13:55:31 CST(-0600)] <anastasiac> jhung: Connect, or Skype?
[13:55:41 CST(-0600)] <jhung> So far jameswy, Erin Yu, Anastasiac, and Jessm have expressed interest in attending.
[13:55:48 CST(-0600)] <jhung> anastasiac: I'
[13:56:05 CST(-0600)] <jhung> m open to either. Skype is easier for conversations
[13:56:33 CST(-0600)] <anastasiac> ok, going online...
[13:57:44 CST(-0600)] <jhung> We'll ping people in a sec. We're going to move machines...
[13:58:39 CST(-0600)] <michelled> jhung: can you include me too? I'm going to just lurk
[13:59:08 CST(-0600)] <Justin_o> jhung: i'd like to join too
[14:00:05 CST(-0600)] <Justin_o> kasper: do you run jslint from the command line?
[14:01:36 CST(-0600)] <Justin_o> michelled,colinclark: this is what the wiki says about jslint options
[14:02:28 CST(-0600)] <Justin_o> The good parts, with "Assume a Browser " turned on, "Disallow ++ and --" turned off, "allow only one var statement per function" turned off, and "Tolerate unfiltered for in" turned on
[14:15:35 CST(-0600)] <harriswong> colinclark, mlam: I think I know why the IE8 is not printing the error correctly. I have altered "onQueueError" to "onFileQueueError" while implementing the errorHandler, and this function also take 2 parameters, (file, error). I think the flash mapper, onQueueError: "file_queue_error_handler" doesn't have these 2 parameters, thus not jumping into the conditions.
[14:16:05 CST(-0600)] <colinclark> harriswong: oops
[14:16:10 CST(-0600)] <harriswong> colinclark, mlam: Do I have to edit the action scripts in order to adjust the "file_queue_error_handler" function?
[14:16:17 CST(-0600)] <colinclark> harriswong: You can't
[14:16:29 CST(-0600)] <colinclark> Basic rule: don't fork other people's code unless you really, really have to
[14:16:41 CST(-0600)] <colinclark> Forking's a big responsibility
[14:16:55 CST(-0600)] <colinclark> and the last code base in the world I want to be responsible for is SWFUpload's
[14:19:25 CST(-0600)] <mlam> does this mean we're in a pickle with flash error reporting?
[14:20:32 CST(-0600)] <kasper> Justin_o: nope, I usually use the website
[14:20:42 CST(-0600)] <mlam> or do we just make the error feedback more generic so that we can have some response with the flash strategy?
[14:20:47 CST(-0600)] <Justin_o> kasper: ah okay.. thanks
[14:21:06 CST(-0600)] <kasper> but I think I use a command line version for my javascript checker script
[14:21:09 CST(-0600)] <kasper> Justin_o, ^
[14:21:14 CST(-0600)] <kasper> lemme check
[14:21:20 CST(-0600)] <Justin_o> kasper: thanks
[14:23:51 CST(-0600)] <colinclark> mlam: I think the thing to do is to think a bit more deeply about why we added arguments to the API, and see if there are other ways we can inject this information for SWFUpload
[14:23:53 CST(-0600)] <colinclark> I'm sure there are ways
[14:24:00 CST(-0600)] <colinclark> but I don't know the motivations for having changed the API like that
[14:24:05 CST(-0600)] <kasper> Justin_o, yeah, the script I made uses offline jslint
[14:24:19 CST(-0600)] <kasper> Justin_o, but it's just a js file
[14:24:26 CST(-0600)] <colinclark> harriswong: Can you talk us through it?
[14:24:37 CST(-0600)] <kasper> run with spidermonkey
[14:29:12 CST(-0600)] <harriswong> colinclark: the parameters are the same as the ones from onFileError. 'file' provide information on the file model itself, ie. file name that failed; 'error' provide the error code, ie. UPLOAD_STOPPED.
[14:29:38 CST(-0600)] <Justin_o> kasper: interesting.. i might bug you about that later
[14:30:35 CST(-0600)] <harriswong> colinclark: the design/approach that i took was to make use of the fluid.uploader.errorConstants to trigger the 2 different errors, same as the ones provided by the wireframe.
[14:32:35 CST(-0600)] <harriswong> colinclark: these errors are, UPLOAD_LIMIT_EXCEEDED, and FILE_LIMIT_EXCEEDED. Using these 2 constants, the function, onFileQueueError(file, error), will be able to add different errors to the errorHandler, and thus handled via there.
[14:36:46 CST(-0600)] <colinclark> I don't quite understand what you actually did, harriswong, aside from rename the event
[14:37:23 CST(-0600)] <colinclark> According to the SWFUpload documentation, the semantics of the fileQueueError event are exactly as you describe:
[14:37:24 CST(-0600)] <colinclark> http://demo.swfupload.org/Documentation/#fileQueueError
[14:37:25 CST(-0600)] <kasper> Justin_o: sure, it's pretty simple ... I can mail you the script if you want me to
[14:37:33 CST(-0600)] <colinclark> (file, error code)
[14:37:45 CST(-0600)] <Justin_o> kasper: thanks that would be nice
[14:37:54 CST(-0600)] <colinclark> So, harriswong, are you saying that there is a bug in SWFUpload that causes it to not pass those arguments?
[14:37:59 CST(-0600)] <colinclark> Or am I missing something?
[14:38:13 CST(-0600)] <harriswong> colinclark: assume it hasn't been renamed. The changes are the 2 parameters which now allow the 2 diff error constants to be added.
[14:39:44 CST(-0600)] <colinclark> I think I'm just not following, harriswong
[14:41:33 CST(-0600)] <colinclark> Looking at SWFUpload's implementation, it looks like the existing fileQueueError event provides all the arguments you need to implement your listener
[14:41:53 CST(-0600)] <colinclark> even if the second argument you take to your ErrorHandler.addError() method is a bit bizarre
[14:42:49 CST(-0600)] <Justin_o> michelled: what does ":true" do in the global variables comments
[14:43:00 CST(-0600)] <Justin_o> colinclark: maybe you know ^
[14:43:23 CST(-0600)] <colinclark> Justin_o: it acknowledges that they're writeable
[14:43:32 CST(-0600)] <Justin_o> colinclark: ah okay..
[14:43:35 CST(-0600)] <colinclark> Otherwise JSLint will complain about writing to a global variable
[14:43:40 CST(-0600)] <colinclark> which is very, very sensible
[14:43:50 CST(-0600)] <colinclark> The only thing we should ever have a :true clause on is the Fluid namespace
[14:44:03 CST(-0600)] <Justin_o> okay thanks.. i wonder if i should standardize the globals comment block too
[14:44:11 CST(-0600)] <colinclark> I guess that will depend on each file
[14:44:25 CST(-0600)] <Justin_o> hmm
[14:44:31 CST(-0600)] <colinclark> But it should definitely be an error if someone writes to a global other than fluid
[14:44:40 CST(-0600)] <Justin_o> right so in a demo file the fluid namespace wouldn't have it, but demo would
[14:44:50 CST(-0600)] <colinclark> yes, exactly
[14:45:17 CST(-0600)] <Justin_o> okay so i'll make another task for fixing up the globals comment block
[14:49:04 CST(-0600)] <harriswong> colinclark: I am reading this http://demo.swfupload.org/Documentation/, didn't know such documentation exist. Catching up on it.
[15:13:07 CST(-0600)] <mlam> colinclark: I'm reading an old chat log about making our decision to have file types expressed as an array rather than a comma-delimited string with regards to file type inclusion. Would you happen to remember what you meant with this statement: " 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"?
[15:13:25 CST(-0600)] <mlam> What do you mean by defining a transformation expander?
[15:13:57 CST(-0600)] <colinclark> This would be anastasiac's cue to make some remark about the fact that I haven't yet written any documentation on transformation expanders
[15:14:36 CST(-0600)] <colinclark> mlam: So, in the abstract, if our file types argument is an array, we can easily notice when a user gives us the old format, because it's a different type--a String
[15:14:59 CST(-0600)] <colinclark> in practice, the way we'd do this is the Model Transformation feature I added to the framework back in 1.3
[15:16:51 CST(-0600)] <mlam> I see. Again referring to the log, we decided that we were going to deprecate the current fileTypes queueSettings option and we were going to replace it with a mimeTypes option. Because we're introducing a brand new option, would we even need to worry about transformations?
[15:17:34 CST(-0600)] <colinclark> Well, there's still the question "what will you do if you encounter a fileTypes option?"
[15:17:45 CST(-0600)] <colinclark> Presumably, you're going to have to transform it into a mimeTypes option
[15:20:23 CST(-0600)] <mlam> I see. Is there a component that currently uses the model transformation feature that i can take a look at?
[15:20:39 CST(-0600)] <colinclark> You can see in the top part of the ModelTransformations.js, mlam, that there are a lot of little functions
[15:21:12 CST(-0600)] <colinclark> these are responsible for taking an input data structure and some options, and producing an alternative output
[15:21:23 CST(-0600)] <anastasiac> did I miss a cue? dammit!
[15:21:28 CST(-0600)] <colinclark> mlam: How about Uploader as an example?
[15:21:52 CST(-0600)] <mlam> ahhh I see them
[15:22:06 CST(-0600)] <colinclark> anastasiac: Unfortunately I spent enough time helping with the README file that I've gone another day without writing docs
[15:22:18 CST(-0600)] <anastasiac> worth it
[15:22:25 CST(-0600)] <colinclark>
[15:22:58 CST(-0600)] <colinclark> mlam: So we'll need some new, Uploader-specific little transformer function that can convert from the fileTypes format into MIME type arrays
[15:23:43 CST(-0600)] <mlam> colinclark: on another note about converting fileTypes-> mimeTypes, I'm having troubles figuring out where I should do these tranformations. Would it sit in Uploader.js and then I would pass this function to the specified strategies with IoC?
[15:24:46 CST(-0600)] <colinclark> mlam: Well, you'll just need to add another entry to the transformation rules for Uploader
[15:25:13 CST(-0600)] <colinclark> So, if you look at the UploaderCompatibilityInfusion1.2.js file, you can see a fairly monstrous data structure
[15:25:30 CST(-0600)] <colinclark> It's not pretty, but that will hopefully change in the future
[15:25:48 CST(-0600)] <colinclark> You'd simply need to add a new entry in here
[15:26:06 CST(-0600)] <colinclark> and it would look something like this:
[15:27:00 CST(-0600)]

[15:27:07 CST(-0600)] <colinclark> There's a bit more to it than that, but not much
[15:27:50 CST(-0600)] <colinclark> Probably we want to write the transformer function itself in a compatibility file
[15:28:08 CST(-0600)] <colinclark> I didn't really think through exactly how we'll introduce new files, but presumably there will be compatibility files appropriate for each new release
[15:28:18 CST(-0600)] <colinclark> and they'll build on previous compatibility files where appropriate
[15:28:35 CST(-0600)] <colinclark> I imagine I'm being very abstract here, mlam
[15:28:38 CST(-0600)] <colinclark> Does this make any sense?
[15:29:00 CST(-0600)] <mlam> hahaa yah, it's pretty abstract. I'm just re-reading the above posts to make more sense of things
[15:29:33 CST(-0600)] <colinclark> So, for the short term, write an algorithm that will do the transformation and put it somewhere publicly-visible
[15:29:38 CST(-0600)] <colinclark> So that you can write unit tests for it, etc.
[15:30:18 CST(-0600)] <colinclark> I'd recommend writing it against the nascent "expander API," which is also part of the documentation I haven't yet written (hi anastasiac!)
[15:30:38 CST(-0600)] <mlam>
[15:30:38 CST(-0600)] <colinclark> Which, so far, involves three arguments
[15:31:05 CST(-0600)] * anastasiac is taking notes, just in case she has to write the docs
[15:31:09 CST(-0600)] <colinclark> 1. "model," which is really the sort object (the thing prior to transformation)
[15:32:01 CST(-0600)] <colinclark> 2. an "expandSpec," which will, in the case of a transformer, definitely have a "path" argument--which represents the target path
[15:32:15 CST(-0600)] <colinclark> as well as an arbitrary set of options suitable for whatever the transformer actually does
[15:32:52 CST(-0600)] <colinclark> 3. "recurse," which the expander may use to recursively process the model, if appropriate (likely not necessary in your case)
[15:33:51 CST(-0600)] <colinclark> Put, another way, your transformer assumes it will get 1) a model that is currently being transformed and 2) a path into the model, pointing at the thing you will transform
[15:34:14 CST(-0600)] <colinclark> And it returns the transformed value
[15:35:07 CST(-0600)] <colinclark> So, we might just put this in the "compat.fluid_1_3.uploader" namespace
[15:35:09 CST(-0600)] <colinclark> ugly as it is
[15:36:24 CST(-0600)]

<colinclark> fluid.compat.fluid_1_3.uploader.fileTypeTransformer = function (model, expandSpec, recurse)

Unknown macro: { var val = fluid.get(model, expandSpec.path); // do something with val; return val; }

;

[15:36:32 CST(-0600)] <colinclark> that's sort of roughly the template you'd use
[15:37:57 CST(-0600)] <mlam> I see.
[15:39:22 CST(-0600)] <colinclark> There's really nothing special about it, in the end
[15:39:41 CST(-0600)] <colinclark> Write a function that chews up fileType strings and spits out mimeType arrays
[15:39:48 CST(-0600)] <colinclark> Write a whole whack of unit tests for it
[15:39:58 CST(-0600)] <mlam> So when we're making this transformation, we'll need a set of values to compare and transform against.
[15:40:07 CST(-0600)] <colinclark> I'll help you with the process of wiring it up to the Uploader
[15:40:14 CST(-0600)] <colinclark> mlam: Values to compare against...
[15:40:16 CST(-0600)] <mlam> Ok, cool.
[15:40:28 CST(-0600)] <colinclark> meaning, a map to convert from file extension to MIME type?
[15:40:41 CST(-0600)] <mlam> Yes
[15:41:17 CST(-0600)] <mlam> so if we're defining a default set of mimeTypes for the uploader, we'll need a hard-coded map to reflect the default mimeTypes to be used against for the transformation, right?
[15:42:27 CST(-0600)] <mlam> that seems strange to me because once the options change, the "hard-coded" map should reflect the new option. does this mean that our conversion map needs to be very extensive? ie. cover all extension types?
[15:43:17 CST(-0600)] <colinclark> mlam: I think it can't
[15:43:21 CST(-0600)] <colinclark> it's a really sticky problem
[15:43:48 CST(-0600)] <mlam> I guess we can put the conversion map into the public namespace for integrators to modify themselves?
[15:43:53 CST(-0600)] <colinclark> If we even could create a comprehensive map of file extension to MIME type, it would be huge
[15:43:55 CST(-0600)] <colinclark> mlam: Yep
[15:46:26 CST(-0600)] <mlam> Ok, I'm understanding more of it now. Thanks colinclark
[15:46:57 CST(-0600)] <colinclark> Bosmon suggested we look at a file in Kettle, which I believe includes a list of MIME types and file extensions
[15:47:06 CST(-0600)] <colinclark> ContentTypes.js or something, it's been ages since I looked at it
[15:47:09 CST(-0600)] <colinclark> let me dig it up
[15:47:56 CST(-0600)] <mlam> Ok
[15:51:44 CST(-0600)] <colinclark> anastasiac: Did any of that help you?
[15:51:51 CST(-0600)] <colinclark> I still fully intend to write that documentation
[15:51:58 CST(-0600)] <colinclark> this week is writing week!
[15:52:21 CST(-0600)] <anastasiac> colinclark, to be perfectly honest, I wasn't actually watching or taking notes (though the logbot was taking notes for me)
[15:52:29 CST(-0600)] <colinclark> lol
[15:52:31 CST(-0600)] <anastasiac> but I suspect whatever is here is extremely helpful
[15:53:12 CST(-0600)] <anastasiac> writing week is good
[15:59:50 CST(-0600)] <colinclark> mlam: https://github.com/fluid-project/kettle/blob/master/src/main/webapp/kettle/js/contentTypes.js
[16:00:15 CST(-0600)] <colinclark> I guess the biggest problem with this particular file is that it really doesn't list content types
[16:00:21 CST(-0600)] <colinclark> it lists "content type headers"
[16:00:47 CST(-0600)] <colinclark> I guess someday we could imagine using your MIME type list to populate this file
[16:00:55 CST(-0600)] <colinclark> so I guess you're more or less on your own there
[16:06:43 CST(-0600)] <mlam> interesting. ok, i think i have more to work from now, thanks!
[16:33:16 CST(-0600)] <jessm> jamon: what's the wiki status? is it completed?