/
fluid-work IRC Logs-2010-01-08

fluid-work IRC Logs-2010-01-08

Jan 08, 2010

[03:38:51 EST(-0500)] * boyan (n=boyan@62.44.108.2) has joined #fluid-work
[03:38:51 EST(-0500)] * boyan (n=boyan@62.44.108.2) has joined #fluid-work
[05:50:08 EST(-0500)] * andreauoc (n=carlos@120.Red-213-96-26.staticIP.rima-tde.net) has joined #fluid-work
[05:50:08 EST(-0500)] * andreauoc (n=carlos@120.Red-213-96-26.staticIP.rima-tde.net) has joined #fluid-work
[05:59:02 EST(-0500)] * sveto_ (n=sveto@62.44.108.2) has joined #fluid-work
[05:59:02 EST(-0500)] * sveto_ (n=sveto@62.44.108.2) has joined #fluid-work
[07:30:17 EST(-0500)] * boyan (n=boyan@62.44.108.2) has left #fluid-work
[07:30:17 EST(-0500)] * boyan (n=boyan@62.44.108.2) has left #fluid-work
[07:52:02 EST(-0500)] * andreauoc (n=carlos@120.Red-213-96-26.staticIP.rima-tde.net) has left #fluid-work
[07:52:02 EST(-0500)] * andreauoc (n=carlos@120.Red-213-96-26.staticIP.rima-tde.net) has left #fluid-work
[08:15:33 EST(-0500)] * Justin_o (n=Justin@142.150.154.171) has joined #fluid-work
[08:15:33 EST(-0500)] * Justin_o (n=Justin@142.150.154.171) has joined #fluid-work
[08:21:10 EST(-0500)] * laurel (n=Laurel@142.150.154.178) has joined #fluid-work
[08:21:10 EST(-0500)] * laurel (n=Laurel@142.150.154.178) has joined #fluid-work
[08:40:30 EST(-0500)] <Justin_o> laurel: i just filed that error issue i found, could you please add your comments to it. http://issues.fluidproject.org/browse/FLUID-3474
[08:40:30 EST(-0500)] <Justin_o> laurel: i just filed that error issue i found, could you please add your comments to it. http://issues.fluidproject.org/browse/FLUID-3474
[08:49:59 EST(-0500)] <laurel> jamon: I would like to check out the apache logs and error files on infusion-builder.fluidproject.org, but don't seem to have permission to view them (or else I am looking in the wrong place).
[08:49:59 EST(-0500)] <laurel> jamon: I would like to check out the apache logs and error files on infusion-builder.fluidproject.org, but don't seem to have permission to view them (or else I am looking in the wrong place).
[09:08:34 EST(-0500)] * anastasiac (n=stasia@dsl-173-206-253-128.tor.primus.ca) has joined #fluid-work
[09:08:34 EST(-0500)] * anastasiac (n=stasia@dsl-173-206-253-128.tor.primus.ca) has joined #fluid-work
[09:12:10 EST(-0500)] * yura (n=yura@142.150.154.170) has joined #fluid-work
[09:12:31 EST(-0500)] <jamon> ok laurel, try logging in again, added that user to the right group
[09:12:10 EST(-0500)] * yura (n=yura@142.150.154.170) has joined #fluid-work
[09:12:31 EST(-0500)] <jamon> ok laurel, try logging in again, added that user to the right group
[09:12:50 EST(-0500)] <laurel> thanks jamon
[09:14:48 EST(-0500)] <laurel> sorry jamon. the logs didn't record yesterday. but basically colinclark was requesting infusion-builder.fluidproject.org/ point to infusion-builder.fluidproject.org/infusionBuilder/html/InfusionBuilder.html via apache redirection.
[09:12:50 EST(-0500)] <laurel> thanks jamon
[09:14:48 EST(-0500)] <laurel> sorry jamon. the logs didn't record yesterday. but basically colinclark was requesting infusion-builder.fluidproject.org/ point to infusion-builder.fluidproject.org/infusionBuilder/html/InfusionBuilder.html via apache redirection.
[09:15:40 EST(-0500)] * jessm (n=Jess@c-71-232-3-151.hsd1.ma.comcast.net) has joined #fluid-work
[09:16:38 EST(-0500)] <jamon> laurel: try zless on the *.gz log files, should be there
[09:17:08 EST(-0500)] <laurel> i meant irc logs that time (wink)
[09:17:24 EST(-0500)] <jamon> i see (smile)
[09:15:40 EST(-0500)] * jessm (n=Jess@c-71-232-3-151.hsd1.ma.comcast.net) has joined #fluid-work
[09:16:38 EST(-0500)] <jamon> laurel: try zless on the *.gz log files, should be there
[09:17:08 EST(-0500)] <laurel> i meant irc logs that time (wink)
[09:17:24 EST(-0500)] <jamon> i see (smile)
[09:38:37 EST(-0500)] * athena (n=athena@adsl-76-250-193-123.dsl.wlfrct.sbcglobal.net) has joined #fluid-work
[09:40:00 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[09:38:37 EST(-0500)] * athena (n=athena@adsl-76-250-193-123.dsl.wlfrct.sbcglobal.net) has joined #fluid-work
[09:40:00 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[09:41:40 EST(-0500)] * boyan (n=boyan@62.44.108.2) has joined #fluid-work
[09:41:40 EST(-0500)] * boyan (n=boyan@62.44.108.2) has joined #fluid-work
[09:51:11 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[09:53:03 EST(-0500)] * clown (n=clown@142.150.154.101) has joined #fluid-work
[09:54:30 EST(-0500)] * jessm (n=Jess@c-71-232-3-151.hsd1.ma.comcast.net) has joined #fluid-work
[09:55:01 EST(-0500)] * colinclark (n=colin@bas2-toronto09-1176130598.dsl.bell.ca) has joined #fluid-work
[09:57:44 EST(-0500)] <Justin_o> colinclark: laurel and I have been looking in the jira you filed yesterday...
[09:57:50 EST(-0500)] <colinclark> great
[09:57:51 EST(-0500)] <Justin_o> we have been able to reproduce it a few times
[09:57:53 EST(-0500)] <colinclark> What are you learning?
[09:58:07 EST(-0500)] <laurel> not much
[09:58:12 EST(-0500)] <Justin_o> yep
[09:58:20 EST(-0500)] <Bosmon> That bulldogs feed on throttles, that burglary's a Science, after all, after all!
[09:59:07 EST(-0500)] <Justin_o> i did find that you can hit one of the php error screens if you do a reload while a package is being built (only in safari though)
[09:59:19 EST(-0500)] <Justin_o> not sure if that is related though so i filed a seperate jira
[09:59:41 EST(-0500)] <laurel> but it isnt' the same error
[09:59:45 EST(-0500)] <colinclark> interesting, Justin_o. Do you have a JIRA ticket for it?
[09:59:58 EST(-0500)] <laurel> and i'm pretty sure I can solve that one.
[10:00:18 EST(-0500)] <laurel> colinclark: i've only been able to reproduce your problem once this morning since 8:30am
[10:00:25 EST(-0500)] <laurel> grrr
[10:00:31 EST(-0500)] <Justin_o> colinclark: http://issues.fluidproject.org/browse/FLUID-3474
[10:00:33 EST(-0500)] <laurel> though justin has done it too
[10:01:27 EST(-0500)] <laurel> however, the css issue we also saw last night I have reproduced half a dozen times
[10:02:04 EST(-0500)] <laurel> any ideas, strategies?
[10:02:10 EST(-0500)] <colinclark> laurel: Have you done any research on issue yet?
[10:02:11 EST(-0500)] <laurel> i'm running out of thoughts.
[10:02:23 EST(-0500)] <laurel> What I do know.
[10:02:35 EST(-0500)] <colinclark> I'm thinking "PHP headers already sent" might be a good start.
[10:02:56 EST(-0500)] <laurel> I am familiar with this kind of error and how to cause it
[10:03:15 EST(-0500)] <colinclark> My usual tool in these kinds of cases is to grab a proxy and take a look at the details of the request and response, both before and as the error occurs.
[10:03:32 EST(-0500)] <laurel> basically, any output that comes before a php function call to "headers"
[10:03:48 EST(-0500)] <laurel> will cause this error to occur
[10:04:32 EST(-0500)] <laurel> however, the error message indicates that the code is failing via a call to postProcessor which is not loaded on first pass to this page
[10:04:42 EST(-0500)] <jamon> would xdebug help?
[10:04:56 EST(-0500)] <laurel> I'm not sure what you mean by "grab....."
[10:05:11 EST(-0500)] <laurel> but I'm looking at the apache logs for the requests
[10:05:30 EST(-0500)] <laurel> but since I can't actually reproduce the error its giving me a bit of a problem.
[10:06:08 EST(-0500)] <laurel> or at least the error doesn't want to occur frequently enough to make it useful...once in 1.5 hrs is not useful.
[10:06:34 EST(-0500)] <laurel> jamon: xdebug?
[10:08:16 EST(-0500)] <jamon> laurel: integrates nicely with eclipse and lets you debug php on the server
[10:09:08 EST(-0500)] <laurel> worth a try
[10:09:25 EST(-0500)] <jamon> laurel: http://techmania.wordpress.com/2008/07/02/debugging-php-in-eclipse-using-xdebug/
[10:09:31 EST(-0500)] <jamon> see the bottom screenshot
[10:09:32 EST(-0500)] <colinclark> laurel: When I say "grab" I mean, load up a proxy server and use it.
[10:30:31 EST(-0500)] * michelled (n=michelle@142.150.154.101) has joined #fluid-work
[10:30:57 EST(-0500)] <colinclark> I'm gonna fire up my debugging proxy and see if I can see anything interesting in the process.
[10:31:36 EST(-0500)] <laurel> colinclark: I'm looking on privoxy right now but taking a while to get up to speed
[10:31:47 EST(-0500)] <colinclark> i'll do it
[10:31:49 EST(-0500)] <laurel> still trying to configure
[10:32:13 EST(-0500)] <laurel> can you beam up - I'd like to look over your shoulder (wink)
[10:32:18 EST(-0500)] <colinclark> Funnily, I think it was Cynick who first conveyed to me the usefulness of proxies for this sort of thing
[10:34:46 EST(-0500)] <laurel> yes, starting to ring some bells, but it's been a long time since I've done this.
[10:34:54 EST(-0500)] <laurel> james recommended privoxy
[10:35:01 EST(-0500)] <laurel> so I'm checking it out...
[10:35:31 EST(-0500)] <laurel> but i still wish there was some way for that error message to be more dependable
[10:36:05 EST(-0500)] <colinclark> The cache is certainly getting some extra priming through this testing
[10:38:06 EST(-0500)] * sveto_ (n=sveto@95.111.16.213) has joined #fluid-work
[10:40:34 EST(-0500)] <colinclark> I'm now struggling to reproduce this issue today
[10:40:53 EST(-0500)] <colinclark> I think if it continues to remain scarce we're going to have to call it, Justin_o
[10:42:49 EST(-0500)] <jamon> i can reproduce it: http://pastebin.ca/1742828
[10:42:54 EST(-0500)] <jamon> different error
[10:43:21 EST(-0500)] * sveto (n=sveto@62.44.108.2) has joined #fluid-work
[10:43:33 EST(-0500)] <jamon> colinclark laurel Justin_o ^
[10:43:58 EST(-0500)] <colinclark> interesting!
[10:44:18 EST(-0500)] <colinclark> jamon: Same steps to reproduce?
[10:44:25 EST(-0500)] <jamon> build, download, reload
[10:44:29 EST(-0500)] <jamon> trying in chrome
[10:44:53 EST(-0500)] <laurel> colinclark: we thought we could reset the mysql database to 1 download to reset the cache after all this
[10:45:16 EST(-0500)] <colinclark> sorry?
[10:46:03 EST(-0500)] <laurel> referering to your thoughts about the cache getting extra priming - we can reset the downloads counters to 1 before announcing...now back to the real problem
[10:46:09 EST(-0500)] <laurel> jamon: you can do this every time?
[10:46:19 EST(-0500)] <jamon> chrome seems fine, checking firefox again
[10:46:29 EST(-0500)] <jamon> let me turn on php error logging first for you laurel
[10:47:05 EST(-0500)] <Justin_o> i haven't been able to reproduce it anywhere but firefox yet
[10:47:21 EST(-0500)] <colinclark> No, I was saying the extra priming was a good thing
[10:48:20 EST(-0500)] <Justin_o> colinclark: we were thinking of resetting the counters so that we could get a count of what users are downloading
[10:48:32 EST(-0500)] <colinclark> ah, for analysis
[10:48:36 EST(-0500)] <colinclark> whatever works
[10:48:50 EST(-0500)] <colinclark> Ok, I still can't reproduce this in FF 3.5 now
[10:51:40 EST(-0500)] <colinclark> Justin_o: You mentioned being able to reproduce the issue in Safari...
[10:51:48 EST(-0500)] <colinclark> By stopping the download and reloading, right?
[10:52:34 EST(-0500)] <colinclark> Could you make this happen consistently, and were you getting the same error message?
[10:54:17 EST(-0500)] <jamon> colinclark: don't have to stop the download in ff3.5 on linux here
[10:54:35 EST(-0500)] <jamon> colinclark: laurel is going to try getting xdebug working in eclipse, i've got it installed on the server
[10:55:08 EST(-0500)] <colinclark> great
[10:56:33 EST(-0500)] <colinclark> jamon: Talk about colourful error messages now
[10:56:41 EST(-0500)] <colinclark> And a real stack trace!
[10:57:30 EST(-0500)] <colinclark> I wonder what it says that I was only finally able to reproduce after quitting my debugging proxy
[10:58:47 EST(-0500)] <jamon> not sure, the php session should be the same regardless, so we can rule that out
[10:59:23 EST(-0500)] <jamon> colinclark: do you have the live http headers extension for firefox? if so, capturing with and without the proxy might be a useful way to compare get/post requests
[10:59:39 EST(-0500)] <colinclark> I don't. Perhaps I should install it.
[11:00:15 EST(-0500)] <jamon> it's handy for many things, always nice to be able to see what the browser is actually doing behind the scenes
[11:00:20 EST(-0500)] <jamon> and it allows replaying requests
[11:00:52 EST(-0500)] <colinclark> perfect
[11:01:06 EST(-0500)] * boyan (n=boyan@62.44.108.2) has left #fluid-work
[11:23:57 EST(-0500)] * michelled (n=michelle@142.150.154.101) has joined #fluid-work
[11:24:22 EST(-0500)] <yura> colinclark: will you be in the office today to chat about data/view generalization concepts?
[11:24:35 EST(-0500)] <colinclark> yep, i'll be in before too long, yura
[11:24:41 EST(-0500)] <colinclark> i'll do standup from home and then head out
[11:24:49 EST(-0500)] <yura> great
[11:24:59 EST(-0500)] <Bosmon> "view generalization"?
[11:25:03 EST(-0500)] <yura> Justin_o and I were thinking a little about it
[11:40:04 EST(-0500)] * sveto (n=sveto@62.44.108.2) has left #fluid-work
[11:52:33 EST(-0500)] <colinclark> So Justin_o, laurel, jamon, here's a little bit of fairly obvious information I've uncovered
[11:52:44 EST(-0500)] <colinclark> Some background first...
[11:52:52 EST(-0500)] <colinclark> The flow of Builder goes something like this
[11:53:11 EST(-0500)] <colinclark> 1. Request the InfusionBuilder.html page. This is a standard GET for an HTML file.
[11:53:38 EST(-0500)] <colinclark> 2. As part of this request, a JSONP-style GET request is made to fetch the JSON model for the Builder's client-side component
[11:53:45 EST(-0500)] <colinclark> 3. Users clicks some checkboxes
[11:53:57 EST(-0500)] <colinclark> 4. Standard HTML form submission upon clicking the download button
[11:54:10 EST(-0500)] <colinclark> so 4. is a POST request
[11:54:22 EST(-0500)] <colinclark> 5. Server responds to this POST with a binary file directly
[11:54:52 EST(-0500)] <colinclark> So when we refresh the page after a download
[11:55:09 EST(-0500)] <colinclark> Firefox is, when the error occurs, reloading that POST request
[11:55:18 EST(-0500)] <colinclark> In turn, the Builder is throwing its error
[11:56:51 EST(-0500)] <Justin_o> colinclark: were you able to determine why in somecases it does the POST request again and others it doesn't?
[11:56:55 EST(-0500)] <colinclark> no
[11:57:19 EST(-0500)] <colinclark> The other thing that is clear is that when I use my proxy server, I can't reproduce the error
[11:57:27 EST(-0500)] <colinclark> As soon as I turn it off, it occurs quite readily
[11:57:54 EST(-0500)] <colinclark> I'd like to head into the office now, but we can catch up on this when I get there
[11:58:21 EST(-0500)] <Justin_o> colinclark: okay... thanks for the update
[11:59:33 EST(-0500)] <laurel> colinclark: I'm some way towards getting the debugger to work, but not there yet
[12:00:04 EST(-0500)] <laurel> because of the rather confusing, html/ php stuff, I'm not sure where to point the debugger configuration
[12:00:22 EST(-0500)] <colinclark> confusing html/php stuff?
[12:00:38 EST(-0500)] <laurel> well, the front page is html which calls some php
[12:01:11 EST(-0500)] <laurel> the debug configuration isn't clear on how to set things up in this case
[12:01:59 EST(-0500)] <laurel> and i can't seem to figure out how to see the code that is broken on when it does figure out where to break
[12:36:04 EST(-0500)] * elicochran (n=elicochr@dhcp-169-229-212-16.LIPS.Berkeley.EDU) has joined #fluid-work
[12:46:38 EST(-0500)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[12:58:30 EST(-0500)] * clown (n=clown@142.150.154.101) has left #fluid-work
[13:18:32 EST(-0500)] * clown (n=clown@142.150.154.190) has joined #fluid-work
[13:49:27 EST(-0500)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[13:52:35 EST(-0500)] <Justin_o> jamon: are you free?
[14:30:00 EST(-0500)] <jamon> Justin_o: at isouth, what's up?
[14:31:16 EST(-0500)] <Justin_o> jamon: hi just wondering if anything has changed on the servers where we have a build of the infusion builder running... so that would be the server we have setup for the daily build and the production server we are testing the deployed version on
[14:31:33 EST(-0500)] <Justin_o> i should have said changes since yesterday
[14:31:58 EST(-0500)] <jamon> nothing on forge, infusion-builder just has xdebug setup
[14:32:14 EST(-0500)] <jamon> but it was an issue yesterday too wasn't it Justin_o?
[14:32:56 EST(-0500)] <Justin_o> jamon: you are right... since yesterday evening... just trying to figure out why we are able to see it so often today
[14:33:48 EST(-0500)] <jamon> more eyeballs?
[14:34:43 EST(-0500)] <Justin_o> possible, but it seems like the rate of reproduction has increased as well... i was able to cause it consistently on every try today but didn't encounter it at all yesterday afternoon
[14:34:56 EST(-0500)] <Justin_o> even though the steps performed were the same
[14:36:13 EST(-0500)] <jamon> think restarting the server would make it go awya for a bit Justin_o?
[14:37:39 EST(-0500)] <Justin_o> jamon: i don't know... do you think it might be a server issue or caused by something that we are running on the server... e.g. mysql
[14:38:05 EST(-0500)] <jamon> don't think so, stock mysql, apache
[14:39:15 EST(-0500)] <Justin_o> jamon: okay... you didn't notice anything strange in any of the server logs either eh?
[14:40:35 EST(-0500)] <jamon> Justin_o: nope, all looks normal
[14:41:25 EST(-0500)] <Justin_o> jamon: thanks for the help...
[14:47:06 EST(-0500)] <jamon> maybe i'm being obtuse, but php's header() function includes a big note stating that include() and require() functions are a common cause of errors.
[14:47:26 EST(-0500)] <jamon> "Remember that header() must be called before any actual output is sent, either by normal HTML tags, blank lines in a file, or from PHP. It is a very common error to read code with include(), or require(), functions, or another file access function, and have spaces or empty lines that are output before header() is called. The same problem exists when using a single PHP/HTML file."
[14:50:29 EST(-0500)] <jamon> i'm wondering if a workaround would be to just redirect the browser after the download starts. then there's no concern about half written html and new headers being reposted
[14:52:08 EST(-0500)] <Justin_o> jamon: so you mean do a redirect to the same page for example?>
[15:09:02 EST(-0500)] <Bosmon> I was chatting with Colin about some concerns that the "current URL state" during the download is a POST URL
[15:09:26 EST(-0500)] <Bosmon> It would certainly be preferable to have performed some kind of redirect, although this would complicate the logic somewhat
[15:10:44 EST(-0500)] <Bosmon> Given the size of the configuration in the form, we would need to transfer the state probably through the session
[15:11:25 EST(-0500)] <Bosmon> All the same, it seems very odd to me that, if we had got the response content type correct, and it was not one that the browser believed it could display, that it would believe the current URL was the POST URL... but, perhaps HTTP being what it is, it has no choice
[15:11:43 EST(-0500)] <Bosmon> But as a general rule, POST URLs should not have content
[15:21:02 EST(-0500)] <jamon> Justin_o, Bosmon, i'm guessing any redirect would work, but here's another idea
[15:21:12 EST(-0500)] <jamon> what about creating a new php sessionid?
[15:21:50 EST(-0500)] <jamon> e.g. download starts, clear the current sessionid, so any post is a completely new request to apache/php? or am i misunderstanding how sessions work?
[15:22:00 EST(-0500)] <jamon> s/post/reload
[15:22:34 EST(-0500)] <Justin_o> jamon: would that trigger a second download?
[15:22:36 EST(-0500)] <Bosmon> Well, that is not how sessions are traditionally meant to be used, no (tongue)
[15:23:03 EST(-0500)] <jamon> presumably if you're reloading, you want another download?
[15:23:17 EST(-0500)] <Bosmon> No, if you are reloading,you should just get the base again
[15:23:27 EST(-0500)] <Bosmon> To get another download, you need to make a further POST
[15:24:26 EST(-0500)] <jamon> Bosmon: i agree that ideally reloading would restart the process, but if (as a 'user') i'm downloading something, and hit reload on the download page, i generally want the file again
[15:25:00 EST(-0500)] <Bosmon> You may "want" it, but it does not make sense to provide it, directly (tongue)
[15:25:15 EST(-0500)] <Bosmon> You will have noticed the slightly indirect way in which download pages general work on the net at large
[15:25:50 EST(-0500)] <jamon> you mean how much they irritate me and how hard it is to wget them? (tongue)
[15:26:16 EST(-0500)] <Bosmon> They have a javascript process which goes on in parallel which sometimes fails, but IN ADDITION there is a perfectly normal "GET" link within the markup which can be triggered manually
[15:26:34 EST(-0500)] <Bosmon> I believe there is a very good reason for this traditional setup, probably not unrelated to the kinds of appalling problems we are having
[15:26:49 EST(-0500)] <Bosmon> Let me reiterate, I believe it is essentialy that the core download itself MUST be triggered by a GET request
[15:26:53 EST(-0500)] <Bosmon> essential
[15:35:46 EST(-0500)] <colinclark> Bosmon: You know, this triggers something for me
[15:36:05 EST(-0500)] <colinclark> I had been pondering, awhile back, how we might implement the Builder's server-side code in Kettle, sooner rather than later.
[15:36:19 EST(-0500)] <colinclark> Now actually doing it is irrelevant
[15:36:19 EST(-0500)] <colinclark> But what I was thinking was...
[15:36:55 EST(-0500)] <colinclark> It actually makes proper semantic sense to, after POSTing the contents of the form, be redirected to a GET request for the file itself.
[15:37:31 EST(-0500)] <colinclark> In other words, if the products of the build were in a Web-visible directory, then a form POST would result in the browser being correctly redirected to actually go GET the file.
[15:37:41 EST(-0500)] <colinclark> Does this make sense, Bosmon and jamon?
[15:38:06 EST(-0500)] <jamon> which is where i chime in and say, yes, mostly, yes. that way i can wget an existing file without needing to resort to lwp-request or other craziness to write custom post parameters
[15:38:26 EST(-0500)] <colinclark> (smile)
[15:39:55 EST(-0500)] <jamon> except, and this is more a lack of existing tools, but where there's javascript involved to get to the page with the GET request, that is rather more difficult to automate, elinks as a text more browser has basic spidermonkey support
[15:40:00 EST(-0500)] <jamon> but it is rudimentary
[15:40:22 EST(-0500)] <jamon> i was showing yura how elinks/wget fail completely on fluidengage.org
[15:40:42 EST(-0500)] <jamon> (i'm an unsympathetic cause, i know (tongue)
[15:44:49 EST(-0500)] <colinclark> wait, why does that happen, jamon?
[15:46:01 EST(-0500)] <Bosmon> Certainly, "morally", this is what we want to be doing
[15:46:33 EST(-0500)] <Bosmon> I am not 100% convinced this should be done by direct exposure of a file directory, but certainly the moral effect should be roughly as if we have
[15:47:54 EST(-0500)] <jamon> one second colinclark, i'll pastebin it
[15:48:15 EST(-0500)] <jamon> Bosmon: doesn't have to be exposed, as long as the get request is to a file that exists, no one has to see a directory listing
[15:49:26 EST(-0500)] <colinclark> yep, that makes sense
[15:49:56 EST(-0500)] <Bosmon> I guess if we are caching these files anyway, we may as well keep doing so
[15:51:17 EST(-0500)] <jamon> ok, colinclark here:http://fluidengage.org/engage/artifacts/browse.html?mccord&amp;Tours when wgetting, http://pastebin.ca/1743166
[15:52:00 EST(-0500)] <jamon> yura pointed out i can wget the json for benchmarking, http://fluidengage.org/engage/artifacts/browse.json?mccord&amp;Tours
[15:52:00 EST(-0500)] <Bosmon> Well yes, we are aware of that kind of thing
[15:52:16 EST(-0500)] <Bosmon> It is the reason that we are writing Kettle the way we are (tongue)
[15:52:17 EST(-0500)] * elicochran (n=elicochr@dhcp-169-229-212-16.LIPS.Berkeley.EDU) has joined #fluid-work
[15:52:25 EST(-0500)] <Bosmon> "In the fullness of time", this markup will also be available from the server
[15:52:43 EST(-0500)] <jamon> excellent
[15:54:04 EST(-0500)] <Bosmon> I mean, that URL structure is clearly entirely wrong too
[15:54:12 EST(-0500)] <colinclark> Yep, jamon, the goal is to be able to treat the issue of where markup is generated, architecturally, as a big "client/server rendering knob," which you could switch freely from all-client to all-server based on context
[15:54:12 EST(-0500)] <Bosmon> We will get these things sorted out as we go (smile)
[15:54:30 EST(-0500)] <colinclark> Which, of course, you can only really do in an environment where everything is in JavaScript (smile)
[15:54:32 EST(-0500)] <Bosmon> Engage 0.1 is really just a "technology experiment"
[15:55:12 EST(-0500)] <jamon> yes, i've gathered as much from listening in on things
[15:56:09 EST(-0500)] <jamon> this is where laurel chimes in, after having patiently chipped away at things and tells us it's already fixed, we can all go home now (big grin)
[15:56:57 EST(-0500)] * laurel is probably not going to have fixed this by the end of the day, but I can certainly work on it
[15:57:21 EST(-0500)] <laurel> all the discussion has been very useful
[15:59:44 EST(-0500)] <laurel> jamon: why do you think this isn't a problem on a local install of apache/php?
[16:00:01 EST(-0500)] <laurel> it would really help if I could reproduce and test locally
[16:00:57 EST(-0500)] <jamon> laurel: mostly because i trust the debian maintainers to do things right
[16:01:07 EST(-0500)] <jamon> (not that we aren't as well)
[16:07:28 EST(-0500)] * laurel (n=Laurel@142.150.154.178) has left #fluid-work
[16:30:46 EST(-0500)] * yura (n=yura@142.150.154.132) has joined #fluid-work
[17:07:38 EST(-0500)] * Justin_o (n=Justin@142.150.154.171) has left #fluid-work
[17:17:58 EST(-0500)] * clown_afk (n=clown@142.150.154.190) has left #fluid-work