fluid-work IRC Logs-2009-05-14

Owned by Fluid IRC Log Bot
Last updated: May 14, 2009Version comment
32 min read

[00:47:17 EDT(-0400)] * lessthanzero (n=FatalRem@CPE001ff342457c-CM001ac352aefc.cpe.net.cable.rogers.com) has joined #fluid-work
[07:33:17 EDT(-0400)] * michelled (n=michelle@CPE001310472ade-CM0011aefd3ca8.cpe.net.cable.rogers.com) has joined #fluid-work
[08:09:16 EDT(-0400)] * jsilvaa (n=jsilva@CABLE-72-53-95-27.cia.com) has joined #fluid-work
[08:21:48 EDT(-0400)] * michelled (n=michelle@CPE001310472ade-CM0011aefd3ca8.cpe.net.cable.rogers.com) has joined #fluid-work
[08:28:25 EDT(-0400)] * Justin_o (n=Justin@142.150.154.171) has joined #fluid-work
[08:30:54 EDT(-0400)] * laurelw (n=Laurel@142.150.154.178) has joined #fluid-work
[09:02:00 EDT(-0400)] * yura (n=yura@142.150.82.64) has joined #fluid-work
[09:02:44 EDT(-0400)] * anastasiac (n=stasia@142.150.154.189) has joined #fluid-work
[09:46:12 EDT(-0400)] * athena (n=athena@99.129.100.66) has joined #fluid-work
[09:59:16 EDT(-0400)] * jessm (n=Jess@c-71-232-1-65.hsd1.ma.comcast.net) has joined #fluid-work
[10:11:06 EDT(-0400)] * clown (n=clown@142.150.154.101) has joined #fluid-work
[10:36:06 EDT(-0400)] * everettz (n=chatzill@74.198.8.57) has joined #fluid-work
[10:36:58 EDT(-0400)] <jsilvaa> laurelw: are you free for a skype call? I want to know how you incorporated UI options on the Fluid site
[10:37:50 EDT(-0400)] <laurelw> can you give me a few minutes. I'm just doing something but I'll be done in a sec.
[10:38:07 EDT(-0400)] <everettz> What time is the Engage chat?
[10:38:40 EDT(-0400)] <jsilvaa> laurelw: no problem, ping me when you are ready
[10:40:46 EDT(-0400)] <jsilvaa> everettz: I think it is at 11am http://www.google.com/calendar/embed?src=u4ts3bmnc6k144uj2oh3aiuumo%40group.calendar.google.com&amp;ctz=America/Toronto
[10:46:36 EDT(-0400)] <everettz> jsilvaa: thanks
[10:50:09 EDT(-0400)] <laurelw> jsilvaa: ready - skype laurelwilliams
[10:54:09 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[10:56:53 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[11:00:12 EDT(-0400)] * everettz (n=chatzill@74.198.8.57) has joined #fluid-work
[11:02:43 EDT(-0400)] <everettz> Getting a Page Cannot be Displayed on : http://connect.yorku.ca/fluid
[11:03:01 EDT(-0400)] <anastasiac> yes, everettz, we're all just commenting that we can't connect
[11:03:13 EDT(-0400)] <anastasiac> it's not working for anyone
[11:04:31 EDT(-0400)] <colinclark> Ok, perhaps we'll have our chat here since Connect appears to be fried.
[11:04:48 EDT(-0400)] <everettz> anastasiac: thanks. It was working 10 mins ago when I tested to make sure I had the correct URL.
[11:04:59 EDT(-0400)] <colinclark> How odd.
[11:07:52 EDT(-0400)] * alisonbenjamin (n=alisonbe@142.150.154.101) has joined #fluid-work
[11:08:48 EDT(-0400)] * yura (n=yura@142.150.82.64) has joined #fluid-work
[11:08:52 EDT(-0400)] * Topic is 'Thursday architecture fireside chat.' set by colinclark on 2009-05-14 11:08:52 EDT(-0400)
[11:09:08 EDT(-0400)] <colinclark> So we'll wait a few minutes for people to trickle in, and then we'll stoke up the fire and chat.
[11:09:11 EDT(-0400)] <colinclark> Literally.
[11:09:13 EDT(-0400)] <colinclark> (wink)
[11:09:16 EDT(-0400)] <michelled> (smile)
[11:09:54 EDT(-0400)] <colinclark> Apologies for the loss of Connect today, but this way we can also accommodate everyone.
[11:11:31 EDT(-0400)] <colinclark> Okay, so I guess we can start.
[11:11:32 EDT(-0400)] <colinclark> Everyone cool?
[11:11:56 EDT(-0400)] * jsilvaa nods
[11:12:01 EDT(-0400)] <anastasiac> we're all very cool
[11:12:06 EDT(-0400)] <laurelw> i'm cool
[11:12:13 EDT(-0400)] * jim-atrc (i=8e969a65@gateway/web/ajax/mibbit.com/x-a1d6f871f2d186b6) has joined #fluid-work
[11:12:16 EDT(-0400)] <colinclark> Awesome.
[11:12:29 EDT(-0400)] <colinclark> So the agenda I sent to the list was pretty open...
[11:12:50 EDT(-0400)] <colinclark> I thought it might be worth chatting a bit about some of the thinking we've been doing in the last week or two in regards to the Engage services layer.
[11:13:01 EDT(-0400)] <colinclark> After that, we can talk about Infusion a bit if we want.
[11:13:16 EDT(-0400)] <colinclark> I'm emphasizing the "chat" part of "fireside chat" here.
[11:13:24 EDT(-0400)] <colinclark> So anyone else have things they want to talk about today?
[11:13:36 EDT(-0400)] <colinclark> Any further questions from last week's location awareness chat?
[11:13:40 EDT(-0400)] <colinclark> etc.
[11:14:40 EDT(-0400)] * fj4000 (n=Jacob@142.150.154.106) has joined #fluid-work
[11:14:48 EDT(-0400)] * davetrey (n=davetrey@73-35-245.uoc.es) has joined #fluid-work
[11:15:14 EDT(-0400)] <colinclark> Hey davetrey, glad you could make it.
[11:15:26 EDT(-0400)] <colinclark> I was just saying that we'll chat a bit about current thinking on the Engage services layer
[11:15:34 EDT(-0400)] <colinclark> And anything else people have to add to the agenda.
[11:15:35 EDT(-0400)] <davetrey> ok
[11:15:37 EDT(-0400)] * jessm (n=Jess@c-71-232-1-65.hsd1.ma.comcast.net) has joined #fluid-work
[11:15:40 EDT(-0400)] <colinclark> Anything on your mind, davetrey?
[11:16:08 EDT(-0400)] <alisonbenjamin> hi everyone.
[11:16:16 EDT(-0400)] <colinclark> Hey alisonbenjamin.
[11:16:31 EDT(-0400)] <colinclark> So, a couple of weeks ago we covered our prospects for services layer technologies.
[11:16:57 EDT(-0400)] <colinclark> We talked a bit about Couch DB as a persistence strategy. We talked about the mismatch between common MVC frameworks and our style of development.
[11:17:11 EDT(-0400)] <colinclark> We talked a bit about the prospects of server-side javascript, Python, etc.
[11:17:31 EDT(-0400)] <colinclark> There was a lot of enthusiasm for server-side JavaScript.
[11:17:39 EDT(-0400)] <colinclark> A couple of reasons for it:
[11:17:58 EDT(-0400)] <colinclark> 1. It would provide us with a unified model: learn one language across a whole technology stack, both client and server.
[11:18:19 EDT(-0400)] <davetrey> Yes, I was thinking about how restful technologies and couchcb (or similar) can work together. I started setting up everything with earlang, aptana, etc... But it's my first time with these tools. So if anyone knows more about aptana - ruby - python - activecouch, I'll very pleased.
[11:18:26 EDT(-0400)] <colinclark> 2. It's ubiquitous: JavaScript is probably the most used language out there.
[11:18:29 EDT(-0400)] <colinclark> davetrey: Excellent.
[11:18:41 EDT(-0400)] <colinclark> Let's add Aptana to the end of the discussion. (smile)
[11:18:45 EDT(-0400)] <davetrey> ok
[11:18:53 EDT(-0400)] <colinclark> So there's ubiquity...
[11:19:19 EDT(-0400)] <colinclark> 3. We would have less infrastructure to write: with JavaScript on the server, we could directly leverage Infusion's Renderer and ChangeApplier libraries.
[11:19:41 EDT(-0400)] <colinclark> These are really core to structuring any Web application in our functional, unobtrusive style.
[11:20:00 EDT(-0400)] <colinclark> So I remember that, among others, michelled was pretty enthusiastic about the prospect of server-side JavaScript.
[11:20:15 EDT(-0400)] <colinclark> For those reasons, and any others?
[11:20:54 EDT(-0400)] <michelled> those were my reasons. we know javascript. we have a javascript framework. lots of other people know javascript too.
[11:21:00 EDT(-0400)] <everettz> js is far less annoying for a visually impaired developer than py
[11:21:13 EDT(-0400)] <colinclark> Well said in both cases.
[11:21:44 EDT(-0400)] <fj4000> everattz: could you elaborate?
[11:21:58 EDT(-0400)] * Bosmo1 (n=Antranig@ginger.caret.cam.ac.uk) has joined #fluid-work
[11:22:00 EDT(-0400)] <fj4000> sorry, everettz: could you elaborate?
[11:22:16 EDT(-0400)] <michelled> spacing as syntax (like python does) just seems like asking for trouble
[11:22:31 EDT(-0400)] <everettz> although there some very good py developers who are blind, the indentation requirements are difficult to work with using a screen-reader.
[11:22:39 EDT(-0400)] <fj4000> oh
[11:22:41 EDT(-0400)] <fj4000> thank you
[11:22:50 EDT(-0400)] <Bosmo1> OK
[11:22:52 EDT(-0400)] <Bosmo1> I am here now
[11:22:56 EDT(-0400)] <colinclark> So that was a pretty good rationale for why server-side JavaScript would rock.
[11:22:58 EDT(-0400)] <Bosmo1> Yes
[11:23:06 EDT(-0400)] <Bosmo1> I looked at some of the performance measurements for Jaxer
[11:23:14 EDT(-0400)] <Bosmo1> And they didn't seem quite as dismal as Nico was saying
[11:23:19 EDT(-0400)] <colinclark> Unfortunately as we dug a bit deeper into the issues, there were pretty huge challenges.
[11:23:21 EDT(-0400)] <Bosmo1> He is here now, so I can chat to him in a bit
[11:23:22 EDT(-0400)] <colinclark> Bosmo1: Interesting.
[11:23:36 EDT(-0400)] <Bosmo1> I wonder if he was trying to take the "recommended route" of working with a DOM on the server
[11:23:38 EDT(-0400)] <Bosmo1> Which is clearly utterly insane
[11:23:50 EDT(-0400)] <colinclark> At heart, server-side JavaScript hasn't really been done much, or well. Jaxer is probably the main example of it in a shipping app.
[11:23:53 EDT(-0400)] <Bosmo1> The measurements reported that for static or near-static files, the performance was very poor too
[11:24:04 EDT(-0400)] <colinclark> And it's based on actually running an instance of Firefox on the server.
[11:24:28 EDT(-0400)] <Bosmo1> I mean, "very poor in particular"
[11:25:09 EDT(-0400)] <colinclark> So Jaxer would not be a likely option for us...
[11:25:17 EDT(-0400)] <colinclark> and given this, we'd be looking at quite a bit of infrastructure to roll ourselves.
[11:25:28 EDT(-0400)] <colinclark> We had been really hopeful that there would be opportunity to collaborate with CollectionSpace.
[11:25:33 EDT(-0400)] <Bosmo1> http://www.aptana.com/jaxer/benchmarks
[11:25:36 EDT(-0400)] <Bosmo1> Here is one page
[11:25:41 EDT(-0400)] <fj4000> is Jaxer an alternative to Rhino?
[11:25:49 EDT(-0400)] <Bosmo1> Well.... should we unpack why Jaxer would not be a likely option for us?
[11:25:51 EDT(-0400)] <Bosmo1> fj4000: Yes
[11:25:58 EDT(-0400)] <colinclark> Bosmo1: Sure, go for it.
[11:26:05 EDT(-0400)] <Bosmo1> fj4000: Although, it is rather an alternative to using a JVM in general
[11:26:19 EDT(-0400)] <Bosmo1> Well no, I was hoping you would unpack it (tongue)
[11:26:26 EDT(-0400)] <colinclark> Sure.
[11:26:39 EDT(-0400)] <Bosmo1> What I see is i) efficiency, ii) if we are not careful, being tied to a very specific model
[11:27:01 EDT(-0400)] <colinclark> Somewhat sarcastically, the idea of embedding a full instance of Firefox on the server is loony.
[11:27:03 EDT(-0400)] <colinclark> But more seriously...
[11:27:11 EDT(-0400)] <colinclark> Jaxer is not a fully open source solution.
[11:27:17 EDT(-0400)] <Bosmo1> ah
[11:27:20 EDT(-0400)] <colinclark> So the issue of being tied to a specific model is worse.
[11:27:24 EDT(-0400)] <Bosmo1> yes
[11:27:36 EDT(-0400)] <colinclark> And the prospects for scalability seem problematic to me.
[11:27:43 EDT(-0400)] <Bosmo1> yes
[11:27:46 EDT(-0400)] <colinclark> At heart, a Web app needs to deal with a fair bit of concurrency.
[11:27:50 EDT(-0400)] <everettz> connect is back.
[11:28:13 EDT(-0400)] <colinclark> Would people prefer to do this in Connect, or just continue here in IRC?
[11:28:30 EDT(-0400)] <colinclark> I guess everettz is still limited to having to make comments via IRC.
[11:28:37 EDT(-0400)] <michelled> I'm fine here if you are
[11:28:45 EDT(-0400)] <michelled> you're and Boz are typing the most
[11:28:49 EDT(-0400)] <Bosmo1> (tongue)
[11:28:58 EDT(-0400)] <anastasiac> the logging of the channel is nice...
[11:28:59 EDT(-0400)] <michelled> that's a good thing (tongue)
[11:29:00 EDT(-0400)] <Bosmo1> I am ok typing
[11:29:06 EDT(-0400)] <colinclark> ok, let's keep going
[11:29:07 EDT(-0400)] <Bosmo1> It makes it easier to deal with my sandwich (tongue)
[11:29:16 EDT(-0400)] <colinclark> Then at least we will have tried it. (smile)
[11:29:23 EDT(-0400)] <colinclark> JavaScript, in its familiar form-running in a browser-is entirely single-threaded.
[11:29:37 EDT(-0400)] <colinclark> You just don't need to worry about contention at all.
[11:29:52 EDT(-0400)] <colinclark> And Jaxer, being still essentially a client-side model, continues that.
[11:30:03 EDT(-0400)] <colinclark> Bosmo1 found some reference to a "cooperative multithreading" approach in Jaxer.
[11:30:16 EDT(-0400)] <Bosmo1> yes
[11:30:20 EDT(-0400)] <Bosmo1> Javascript and threading don't really mix
[11:30:24 EDT(-0400)] <colinclark> But that seems awfully reminiscent of the '80s style of Mac OS toolbox programming. (wink)
[11:30:36 EDT(-0400)] <Bosmo1> For no particularly inherent reason, but just that nobody has been doing it, historically
[11:30:42 EDT(-0400)] <colinclark> Yes, exactly.
[11:30:43 EDT(-0400)] <colinclark> So, Jaxer has never been a serious contender in my mind at least.
[11:30:51 EDT(-0400)] <colinclark> We had been optimistic about sharing with CollectionSpace.
[11:30:53 EDT(-0400)] <Bosmo1> A Rhino solution would at least inherit the known threading primitives of a JVM
[11:31:02 EDT(-0400)] <colinclark> Dan Sheppard has done some preliminary work with a Rhino solution.
[11:31:08 EDT(-0400)] <colinclark> I'll dig up a link to the source code in case people are curious.
[11:31:19 EDT(-0400)] <Bosmo1> Rhino, of course, is on a much slower performance trajectory
[11:31:35 EDT(-0400)] <Bosmo1> Jaxer, through being able to use the whole of Firefox, gets near-instant access to whatever engineering Mozilla do
[11:31:41 EDT(-0400)] <Bosmo1> Whereas Rhino seems near-stalled
[11:31:56 EDT(-0400)] <colinclark> So, to be clear, Rhino is a pure Java interpreter for JavaScript.
[11:32:09 EDT(-0400)] <colinclark> It was written quite awhile ago, and while it is maintained by Mozilla, not much is being done on it.
[11:32:17 EDT(-0400)] <colinclark> And we are on the cusp of a whole new generation of JS runtimes.
[11:32:36 EDT(-0400)] <Bosmo1> so, it is not quite fair to say that Rhino is talled
[11:32:37 EDT(-0400)] <Bosmo1> stalled
[11:32:38 EDT(-0400)] <colinclark> Rhino doesn't appear to be the recipient of any of this tracing love.
[11:32:38 EDT(-0400)] <Bosmo1> http://blog.norrisboyd.com/2009/03/rhino-17-r2-released.html
[11:32:58 EDT(-0400)] <colinclark> There is a Summer of Code student working on ECMAScript 5 support for it.
[11:33:04 EDT(-0400)] <colinclark> But it's sort of inching along.
[11:33:10 EDT(-0400)] <Bosmo1> yes
[11:34:03 EDT(-0400)] <Bosmo1> Remind me, does ECMAScript 5 comprise "Javascript 1.7"? (tongue)
[11:34:22 EDT(-0400)] <colinclark> It's the revised "Harmony" stuff.
[11:34:31 EDT(-0400)] <colinclark> Meaning not-so-ambitious next gen JS.
[11:34:38 EDT(-0400)] <colinclark> Used to be called ECMAScript 3.1, I believe.
[11:34:55 EDT(-0400)] <colinclark> Here's some Rhino-related code from CollectionSpace: https://source.collectionspace.org/collection-space/src/application/trunk/src/rhion-config-csp/src/main/java/org/collectionspace/xxu/
[11:35:05 EDT(-0400)] <colinclark> Unfortunately Dan's vision of JS in CollectionSpace is fairly limited.
[11:35:16 EDT(-0400)] <Bosmo1> "The last 1.7R1 version relies on the Java 5 platform, and supports version 1.7 of JavaScript[4]."
[11:35:20 EDT(-0400)] <colinclark> A quick extension point for developers to add a bit of plugin logic, and that's it.
[11:35:36 EDT(-0400)] <colinclark> He particularly wants to sidestep some of the issues that would be key for us.
[11:35:45 EDT(-0400)] <Bosmo1> "JavaScript 1.7's generators and array comprehensions are two recent examples."
[11:36:01 EDT(-0400)] <colinclark> Building the request/response infrastructure, managing a web container with request-, application-, and session-level scoping, etc.
[11:36:17 EDT(-0400)] <colinclark> Ultimately, many of these problems fall back to the issue of concurrency
[11:36:29 EDT(-0400)] <Bosmo1> Yes
[11:36:29 EDT(-0400)] <colinclark> And the fact that typical JavaScript just doesn't contend with these issues.
[11:36:32 EDT(-0400)] <colinclark> It's not that it can't.
[11:36:42 EDT(-0400)] <colinclark> It's just that we haven't had any need to address it in the browser context.
[11:36:56 EDT(-0400)] <colinclark> We speculate that the vast majority of Infusion would be prepared for concurrency.
[11:36:59 EDT(-0400)] <Bosmo1> Although I believe the overall web container interface is an even more core issue
[11:37:05 EDT(-0400)] <colinclark> But the point is that in any other language, you can just got get a book about threading best practices.
[11:37:08 EDT(-0400)] <colinclark> Bosmo1: Yes, true.
[11:37:14 EDT(-0400)] <Bosmo1> With the slight exception of parts of the renderer - but that would just be a few hours to fix
[11:37:21 EDT(-0400)] <Bosmo1> I was lazy in the way I scoped the entire file
[11:37:39 EDT(-0400)] <colinclark> Do you want to get into that in a sec? The web container interface? We'll just finish up on the concurrency issue.
[11:37:45 EDT(-0400)] <Bosmo1> So, colinclark - I missed the bit before
[11:37:46 EDT(-0400)] <Bosmo1> Ok, sorry
[11:37:47 EDT(-0400)] <Bosmo1> carry on
[11:37:49 EDT(-0400)] <colinclark> no worries
[11:37:50 EDT(-0400)] <colinclark> this is good
[11:37:55 EDT(-0400)] <colinclark> So we'd be contending with an interesting situation...
[11:38:07 EDT(-0400)] <colinclark> A language we are all familiar with--and that many of our users will be familiar with...
[11:38:10 EDT(-0400)] <colinclark> which is great.
[11:38:18 EDT(-0400)] <colinclark> But a whole new context for how our code is executed.
[11:38:22 EDT(-0400)] <Justin_o> colinclark: were you saying that we would be using java's threading if we use rhino?
[11:38:24 EDT(-0400)] <colinclark> And no one else has really done this before.
[11:38:31 EDT(-0400)] <Bosmo1> Justin_o: That is right
[11:38:42 EDT(-0400)] <Justin_o> okay
[11:38:53 EDT(-0400)] <colinclark> So then, we'd be figuring out all the "best practices" as we go...
[11:39:00 EDT(-0400)] <Bosmo1> Actually, one thing that should be mentioned, is the common (and I think correct) "opinion" that a "well-written server-side application should have little interest in explicit concurrency"
[11:39:02 EDT(-0400)] <colinclark> and have a fairly heavy burden to educate everyone on what not to do.
[11:39:23 EDT(-0400)] <colinclark> Bosmo1: Yes. I'm sure people would be interested in an elaboration.
[11:39:27 EDT(-0400)] <Bosmo1> Really, our general use of closures and avoidance of shared modifiable state answers most of the issues we should expect to contend with
[11:39:55 EDT(-0400)] <Bosmo1> We have a lot of "framework best practices" which go a long way towards ensuring the way our infrastructure is put together is generally "cleanly"
[11:40:08 EDT(-0400)] <Bosmo1> Going towards a server-side would probably require us to shore up our advice in a few areas
[11:40:27 EDT(-0400)] <Bosmo1> But really, widespread use of closures address considerable parts of the problem space that concurrency creates
[11:40:42 EDT(-0400)] <Bosmo1> If a closure is private to your code, it is really private
[11:40:54 EDT(-0400)] <Bosmo1> All you need to make sure is, that the units you share closures in do not cross thread boundaries
[11:41:18 EDT(-0400)] <Bosmo1> As it stands, renderer is probably the only "dirty" area of our codebase - it reuses its file-wide closure scope to store common variables during a rendering operation
[11:41:26 EDT(-0400)] <Bosmo1> Which is a classic example of the sort of thing not to do
[11:41:36 EDT(-0400)] <colinclark> One of the reasons I generally feel that we are more comfortable working in a functional language for Engage.
[11:41:50 EDT(-0400)] <Bosmo1> The only real reason I did this was to avoid having to indent the entire file one level deeper....
[11:41:54 EDT(-0400)] <colinclark> (smile)
[11:41:57 EDT(-0400)] <Justin_o> so each closre would be a thread
[11:42:00 EDT(-0400)] <Bosmo1> or else, to create a new "data structure" storing these common variables
[11:42:05 EDT(-0400)] <Bosmo1> Justin_o: Not really
[11:42:12 EDT(-0400)] <Bosmo1> Closures are just little "islands"
[11:42:17 EDT(-0400)] <Bosmo1> You can share them out however you like
[11:42:38 EDT(-0400)] <Bosmo1> It's just that, you should make sure that if a closure is "long-lived", it does not end up being executed by multiple threads
[11:42:51 EDT(-0400)] <Bosmo1> Having lots of fine-grained closures is a good way to ensure that you can divide up your application sensibly
[11:43:12 EDT(-0400)] <Bosmo1> To be honest, I don't imagine we will bump into these issues at all in this form, since, in an RSF-like way, I don't imagine we plan to have very much stored in the server between requests
[11:43:27 EDT(-0400)] <Bosmo1> However, once users start stressing you with their requirements, it is easy to start taking sloppy and easy ways out
[11:43:48 EDT(-0400)] <Bosmo1> For example - I don't imagine right now we will have much need for something resembling a kind of "component" on the server, which lives between requests
[11:43:55 EDT(-0400)] <Bosmo1> THat would actually represent a kind of error
[11:44:00 EDT(-0400)] <colinclark> Bringing us back to the point that the burden will be on us to both identify potential sloppiness and educate our entire community on how to avoid it.
[11:44:13 EDT(-0400)] <colinclark> Bosmo1: Yes, great point.
[11:44:21 EDT(-0400)] <colinclark> The server world is a world of one-offs
[11:44:24 EDT(-0400)] <Bosmo1> Even though it is an "error", which in many programming communities, amounts to a "design practice" (tongue)
[11:44:38 EDT(-0400)] * alisonbenjamin (n=alisonbe@142.150.154.101) has joined #fluid-work
[11:44:39 EDT(-0400)] <colinclark> Ideally state is destroyed upon satisfying a request.
[11:44:42 EDT(-0400)] <Bosmo1> For example, the entire JSF framework is based on this kind of error
[11:45:06 EDT(-0400)] <colinclark> So I think that roughly outlines our concern with the server-side JavaScript approach.
[11:45:19 EDT(-0400)] <colinclark> It's an immensely rich option, but it has a number of issues.
[11:45:26 EDT(-0400)] <Bosmo1> So - you just have to be careful - and whenever you write a piece of server-side code, be extremely clear what you believe its concurrency/sharing model is
[11:45:38 EDT(-0400)] <Bosmo1> The ultimate, is a function with no side-effects... these enjoy golden status in all viewpoints
[11:45:43 EDT(-0400)] <Bosmo1> And is in fact the "functional ideal"
[11:45:50 EDT(-0400)] <colinclark> Do you want to cover the "considerable infrastructure gaps" in JavaScript, Bosmo1. Particularly wrt to container infrastrcture?
[11:45:55 EDT(-0400)] <Bosmo1> And, for example, is the kind of javascript we will write inside CouchDB
[11:46:18 EDT(-0400)] <Bosmo1> CouchDB insists that all Javascript "view snippets" are sideeffect-free like this... as well as satisfying a few even stronger guarantees
[11:46:24 EDT(-0400)] <Bosmo1> colinclark: ok
[11:46:33 EDT(-0400)] <Bosmo1> Although really, the "gaps", in Javascript, are pretty complete
[11:46:51 EDT(-0400)] <Bosmo1> There is no established, or even up-and-coming standard for interfacing with a web container in Javascript
[11:47:10 EDT(-0400)] <Bosmo1> Which is why, from the start, we always imagined we would try to "look sideways" and borrow bits of these standards from some neighbouring frameworks
[11:47:34 EDT(-0400)] <Bosmo1> One interesting point Colin and I shared in a chat last week, was how "object literals" in Python actually, look exactly like JSON
[11:47:49 EDT(-0400)] <Bosmo1> A Python "dictionary" is in fact, simply the equivalent of a Javascript "object"...
[11:48:06 EDT(-0400)] <Bosmo1> So, looking at Python standards for web containers makes sense in terms of the reasonable cognateness of these two languages
[11:48:13 EDT(-0400)] <Bosmo1> Even if code doesn't look the same, at least data does
[11:48:21 EDT(-0400)] <Bosmo1> An interesting Python container standard is called "WSGI"
[11:48:32 EDT(-0400)]

<colinclark> myDict =

Unknown macro: {foo}

, for example


[11:48:33 EDT(-0400)] <Bosmo1> Which covers a very great proportion of the issues we are interested in
[11:49:15 EDT(-0400)] <Bosmo1> http://linuxgazette.net/115/orr.html
[11:49:27 EDT(-0400)] <Bosmo1> This is a very good page that explains what it covers, and the kind of variations it is capable of accommodating
[11:49:57 EDT(-0400)] <Bosmo1> Promisingly this also covers variation due to threading models, as well as being "in-process" or "out-of-process" wrt. the originating container
[11:50:07 EDT(-0400)] <Bosmo1> Although the page does mention that WSGI covers this by explicitly requiring to be "in-process" (tongue)
[11:50:23 EDT(-0400)] <colinclark> So, while it's viable to do JavaScript on the server--either through Rhino or ultimately through a faster, embedded engine such as TraceMonkey or V8....
[11:50:27 EDT(-0400)] <Bosmo1> Anyway, the fact is, that in Python, this is very well-trodden ground
[11:50:34 EDT(-0400)] <Bosmo1> Whereas in Javascript it is utterly virgin territory
[11:50:34 EDT(-0400)] <colinclark> The problem is that there's still this chunk of infrastructure missing.
[11:50:55 EDT(-0400)] <colinclark> The stuff we use to process requests, map it to our own logic, and respond to it.
[11:51:24 EDT(-0400)] <Bosmo1> So, my inclination, is at least, to start by considering the Python container and request model as our basis - independently of the decision ultimately as to which language we write in
[11:51:47 EDT(-0400)] <Bosmo1> If we wrote in javascript, I would say our best option would be to simply try to replicate Python artefacts and standards for web requests in any case
[11:51:57 EDT(-0400)] <colinclark> And my inclination, at this stage, is probably more drastic...
[11:52:24 EDT(-0400)] <Bosmo1> To get a sandwich? (tongue)
[11:52:31 EDT(-0400)] <colinclark> And that's to say that while server-side JavaScript is our ideal implementation, we're probably not in a good position to address the 1) infrastructure gaps and 2) the techniques to do it.
[11:52:42 EDT(-0400)] <colinclark> And a simple, incremental Python approach is foremost on my mind.
[11:52:50 EDT(-0400)] <colinclark> keep in mind that we're still in the brainstorming stage.
[11:52:50 EDT(-0400)] <Bosmo1> Well, that is really my "inclination" too
[11:52:54 EDT(-0400)] <colinclark> so this is just an opinion. (smile)
[11:52:57 EDT(-0400)] <colinclark> Bosmo1: Cool.
[11:53:00 EDT(-0400)] <Bosmo1> Although there is this interesting gap between "what you do", and "what you say you are doing" (tongue)
[11:53:02 EDT(-0400)] <colinclark> A sandwich would be great, too.
[11:53:11 EDT(-0400)] <Bosmo1> I mean, we could "say we are pursuing the option of Javascript on the server"
[11:53:17 EDT(-0400)] <Bosmo1> But all the same, not do anything practical about it for a year or more
[11:53:24 EDT(-0400)] <colinclark> So this is a good time to pause for questions, probably.
[11:53:29 EDT(-0400)] <colinclark> We've covered a ton.
[11:53:32 EDT(-0400)] <colinclark> Any questions?
[11:53:42 EDT(-0400)] <colinclark> We can back up and cover details, or whatever, if anyone wants.
[11:54:13 EDT(-0400)] <Bosmo1> Whilst, yes, as Colin says, "server-side JavaScript is our ideal implementation", I don't think we should set out by doing anything practical in that direction right now
[11:54:33 EDT(-0400)] <colinclark> Yeah, I think Bosmo1's point is interesting here. Which is to say that a unified, all-JavaScript environment is still our ideal, but not practical in the first year. So we build with Python, and keep an eye on how the JavaScript option evolves over time.
[11:54:34 EDT(-0400)] <colinclark> ha
[11:54:42 EDT(-0400)] <colinclark> we pretty much just typed the same thing there
[11:54:44 EDT(-0400)] <Bosmo1> (smile)
[11:54:45 EDT(-0400)] <colinclark> (tongue)
[11:54:56 EDT(-0400)] <Bosmo1> or else, completely different things, which lead to exactly the same course of action (tongue)
[11:54:56 EDT(-0400)] <colinclark> Ok, questions/comments/complaints/commendations?
[11:55:04 EDT(-0400)] <michelled> although I was really excited with the idea of server side javascript we always knew it was slightly crazy.
[11:55:10 EDT(-0400)] <colinclark> Compliments? (tongue)
[11:55:12 EDT(-0400)] <Bosmo1> if we are not careful, we might end up "in violent agreemtn"
[11:55:13 EDT(-0400)] <colinclark> michelled: ha
[11:55:13 EDT(-0400)] <Bosmo1> ent
[11:55:41 EDT(-0400)] * michelled has always wanted to learn python
[11:56:00 EDT(-0400)] <Bosmo1> I think I share everettz general aversion to the form of python
[11:56:08 EDT(-0400)] <Bosmo1> But it is certainly not completely immoral
[11:56:28 EDT(-0400)] <michelled> colinclark: one thing we talked about when I was working on the server side javascript for the build scripts was debugging support
[11:56:35 EDT(-0400)] <Bosmo1> Also, I like to dwell on my observation that the "JSON-ic" subset of Python and Javascript is actually identical
[11:56:36 EDT(-0400)] <colinclark> It's undoubtedly going to involve some cognitive load to switch from Py's idiosyncratic syntax vs. JavaScript's C-like style.
[11:56:39 EDT(-0400)] <michelled> I didn't actually try the rhino debugger - has anyone else?
[11:56:57 EDT(-0400)] <colinclark> This notion of emphasizing things that are JSONic is important for us.
[11:57:00 EDT(-0400)] <Bosmo1> And, that a core goal of our framework as well as general idiom, is to reduce as much coding as possible to the data-driven, JSON-ic subset
[11:57:11 EDT(-0400)] <colinclark> It's, again, an assertion of the value of working declaratively.
[11:57:29 EDT(-0400)] <Bosmo1> Another thing Colin and I shared, was the importance of, perhaps, writing any Python we do, with an eye to subsequently Javascript-ising it
[11:57:30 EDT(-0400)] <colinclark> michelled: I haven't had a chance to fire up the Rhino debugger, no.
[11:57:39 EDT(-0400)] <Bosmo1> And we tried to explore what in particular that might mean
[11:57:44 EDT(-0400)] <colinclark> I had wondered about the prospect of firing up Rhino along with Resig's env.js and run some of Bosmo1
[11:57:50 EDT(-0400)] <colinclark> Bosmo1's old JS benchmarks on it.
[11:57:54 EDT(-0400)] <colinclark> Along with playing with the debugger.
[11:57:55 EDT(-0400)] <Bosmo1> Many of the features which apparently make Python distinctive, are really just sugar
[11:58:11 EDT(-0400)] <Bosmo1> For example, list comprehensions, destructuring assignment, etc.
[11:58:32 EDT(-0400)] <Bosmo1> And actually are fairly easy to transfer into near-Pythonic javascript - certainly much easier than transferring them into Java
[11:58:33 EDT(-0400)] <colinclark> The sugar tastes quite good from my early playing with Python, I will admit. (wink)
[11:58:41 EDT(-0400)] <Bosmo1> The only core area of mismatch is in the object idiom
[11:58:41 EDT(-0400)] <laurelw> can someone type in a few refs to Rhino so I can go back later and read?
[11:58:43 EDT(-0400)] <colinclark> Several of these bits of sugar are coming to JS, as well.
[11:58:53 EDT(-0400)] <Bosmo1> Which, as we recall, we have completely denigrated in javascript in any case
[11:58:54 EDT(-0400)] <colinclark> laurelw: You should get a good hit from Googling Rhino
[11:58:58 EDT(-0400)] <colinclark> You're looking for the Mozilla page.
[11:59:04 EDT(-0400)] <Bosmo1> colinclark: Not in fact
[11:59:12 EDT(-0400)] <Bosmo1> You would be amazed at the junk you get by googling Rhino (tongue)
[11:59:15 EDT(-0400)] <colinclark> "Rhino debugger" will get you info on the debugger.
[11:59:25 EDT(-0400)] <colinclark> Bosmo1: really? I was pretty sure it was the third hit
[11:59:28 EDT(-0400)] <colinclark> "Rhino Java" maybe?
[11:59:33 EDT(-0400)] <Bosmo1> Yeah
[11:59:36 EDT(-0400)] <Bosmo1> Or rhino Javascript
[11:59:39 EDT(-0400)] <laurelw> thx..rhino isn't enough
[11:59:44 EDT(-0400)] <Bosmo1> I got any number of bands, or products named Rhino
[12:00:07 EDT(-0400)] <Bosmo1> I think the Wikipedia page is actually a pretty excellent guide
[12:00:11 EDT(-0400)] <Bosmo1> Well
[12:00:13 EDT(-0400)] <Bosmo1> It is a start
[12:00:39 EDT(-0400)] <colinclark> Ok, so. No more questions, comments?
[12:00:48 EDT(-0400)] <colinclark> She's still following, but chatting with a student about helping with docs.
[12:01:00 EDT(-0400)] <colinclark> Bosmo1: That is, anastasiac, I mean.
[12:01:15 EDT(-0400)] <laurelw> apparently though there is a javan rhino , just to confuse the searching issue
[12:01:17 EDT(-0400)] <colinclark> Bosmo1 was asking if anastasiac had questions.
[12:01:24 EDT(-0400)] <Bosmo1> (smile)
[12:01:49 EDT(-0400)] <colinclark> Justin_o: Anything on your mind?
[12:02:05 EDT(-0400)] <colinclark> jsilvaa, yura: any questions or thoughts?
[12:02:15 EDT(-0400)] <colinclark> michelled, Justin_o, laurelw: how about you guys? still awake?
[12:02:16 EDT(-0400)] <colinclark> (wink)
[12:02:32 EDT(-0400)] <colinclark> If no other questions, I can summarize...
[12:02:36 EDT(-0400)] <colinclark> And then we can move on.
[12:02:38 EDT(-0400)] <michelled> yup - pondering the implications of python
[12:02:41 EDT(-0400)] <laurelw> Ok, so I also can't find much on the relationship between rhino and python (yes, I'm trying to research as this discussion is proceeding)
[12:02:45 EDT(-0400)] <jsilvaa> no questions from me
[12:02:50 EDT(-0400)] <Bosmo1> laurelw: There is no explicit relationship
[12:02:54 EDT(-0400)] <Bosmo1> But we will explain more in our next section
[12:03:08 EDT(-0400)] <colinclark> Bosmo1: What is the next section?
[12:03:11 EDT(-0400)] <Bosmo1> Ah
[12:03:18 EDT(-0400)] <Bosmo1> i thought I would start talking about Jython (tongue)
[12:03:25 EDT(-0400)] <colinclark> Bosmo1: Fire away. (smile)
[12:03:27 EDT(-0400)] <laurelw> ok. but the two are linked in our discussion, so I'm trying to figure out where rhino fits and where python fits
[12:03:36 EDT(-0400)] <colinclark> Let me give a second of background info...
[12:03:41 EDT(-0400)] <Bosmo1> laurelw: Yes, this will now be explained
[12:03:44 EDT(-0400)] <laurelw> thx colinclark
[12:03:52 EDT(-0400)] <colinclark> So if you remember why we liked JS so much...
[12:03:54 EDT(-0400)] <Bosmo1> So far we have only talked about their "cognate relationship"
[12:04:00 EDT(-0400)] <Justin_o> colinclark: i'm still catching up
[12:04:09 EDT(-0400)] <Bosmo1> In terms of being things which embody similar sorts of practices or ways of thinking about code
[12:04:11 EDT(-0400)] <laurelw> yup
[12:04:13 EDT(-0400)] <colinclark> We said that JavaScript was appealing because we already have really important infrastructure in it.
[12:04:21 EDT(-0400)] <Bosmo1> But it turns out, that there is a route for linking them physically as well
[12:04:25 EDT(-0400)] <colinclark> It's pretty clear that the Renderer and ChangeApplier are awesome.
[12:04:32 EDT(-0400)] <colinclark> And would form the backbone of code on the server as well as the client.
[12:04:47 EDT(-0400)] <Bosmo1> A reasonably popular implementation of Python is called "Jython" - which is, an implementation of Python for the JVM, which is historically used to deliever Java applications
[12:04:52 EDT(-0400)] <colinclark> So the challenge with Python is that we'd have to port versions of these libraries.
[12:05:11 EDT(-0400)] <Bosmo1> It may seem that colinclark and I are talking about unrelated threads, but we are actually converging on the same issue (tongue)
[12:05:22 EDT(-0400)] <colinclark> Bosmo1: I think we have converged sufficiently...
[12:06:09 EDT(-0400)] <colinclark> In that Jython provides us with a means to address missing libraries as well as the issue of potentially still leveraging some JS>
[12:06:18 EDT(-0400)] <colinclark> Bosmo1: Does that make sense?
[12:07:03 EDT(-0400)] <Bosmo1> Yes
[12:07:23 EDT(-0400)] <colinclark> Justin_o just asked a question by voice.
[12:07:32 EDT(-0400)] <colinclark> "Is Jython basically like Rhino for Python?"
[12:07:33 EDT(-0400)] <Bosmo1> The common basis on a JVM produces at least a conceivable physical route by wich we might "gradually" migrate our architecture to Javascript
[12:07:33 EDT(-0400)] <Justin_o> sorry (sad)
[12:07:40 EDT(-0400)] <Bosmo1> Bear in mind that we are not really committing ourselves to anything
[12:07:44 EDT(-0400)] <colinclark> So we should clarify that first.
[12:07:51 EDT(-0400)] <Bosmo1> We want everything we write to be as maximally, and easily portable as possibl
[12:08:06 EDT(-0400)] <Bosmo1> We don't want users to write any code which expresses a commitment to the JVM
[12:08:07 EDT(-0400)] <colinclark> The JVM is a platform on which many languages can run. Jython is a Python runtime for the JVM.
[12:08:11 EDT(-0400)] <colinclark> And it is well maintained
[12:08:27 EDT(-0400)] <Bosmo1> We should be free, some months or years down the line, be capable of throwing away the JVM entirely, if this ends up making sense for other reasons
[12:08:56 EDT(-0400)] <Bosmo1> For example, those other reasons might include the fact that Google unveils a fantastic, all-singing-and-wheezing completely open source server-side Javascript infrastucture
[12:09:02 EDT(-0400)] <Bosmo1> Or, for that matter, Python infrastructure
[12:09:12 EDT(-0400)] <Bosmo1> So far, they have not done this, and may never do so
[12:09:21 EDT(-0400)] <colinclark> It's anyone's guess.
[12:09:27 EDT(-0400)] <colinclark> Though it doesn't seem entirely unlikely.
[12:09:32 EDT(-0400)] <colinclark> Google sort of does everything.
[12:09:33 EDT(-0400)] <Bosmo1> Google always "backs every horse"
[12:09:34 EDT(-0400)] <Bosmo1> yes
[12:09:49 EDT(-0400)] <colinclark> Which is a good reason not to model Google for "best practices." (tongue)
[12:09:56 EDT(-0400)] <colinclark> Anyway, sorry.
[12:09:59 EDT(-0400)] <colinclark> Carry on, Bosmo1.
[12:10:08 EDT(-0400)] <Bosmo1> Well, they are the best practices, for a company with near-infinite resources (tongue)
[12:10:20 EDT(-0400)] <colinclark> lol
[12:10:25 EDT(-0400)] <Bosmo1> Us less quantum-capable beings have to put up with just doing one thing at a time
[12:10:49 EDT(-0400)] <Bosmo1> Anyway, yes - use of Jython seems plausible from a number of fronts
[12:11:26 EDT(-0400)] <Bosmo1> i) it allows us access to established libraries that are on the JVM - amongst which we can comprise some libraries which embody algorithms we are interested in, such as our template renderer
[12:12:04 EDT(-0400)] <Bosmo1> ii) it still allows us access to a good number of near-native Python idioms for talking to a web container - for example, sgithens342f has told me that the Jython engine essentially does the work of mapping an incoming Java Servlet request/response pair to a WSGI form
[12:12:18 EDT(-0400)] <colinclark> That's excellent!
[12:12:25 EDT(-0400)] <laurelw> wsgi?
[12:12:29 EDT(-0400)] <Bosmo1> iii) it also provides an environment in which we could experiment with mapping parts of our infrastructure into Javascript, should we have resources or inclination to do so
[12:12:46 EDT(-0400)] <colinclark> laurelw: http://www.wsgi.org/wsgi/What_is_WSGI
[12:12:56 EDT(-0400)] <colinclark> First hit from googling "wsgi"
[12:13:12 EDT(-0400)] <colinclark> And to address michelled's point, it provides first-class tools.
[12:13:15 EDT(-0400)] <colinclark> IDE, debugger, etc.
[12:13:34 EDT(-0400)] <Bosmo1> Oh yes, I should have mentioned that
[12:13:35 EDT(-0400)] <Bosmo1> as iv)
[12:13:52 EDT(-0400)] <Bosmo1> Also, talking to sgithens342f, he confirms that pdb, the python debugger, is possible to deploy on a Jython app
[12:14:04 EDT(-0400)] <Bosmo1> Although it may require a bit of tinkering
[12:14:23 EDT(-0400)] <colinclark> So the point here is that the JVM represents a platform on which we can build Engage, potentially mixing languages where needed to get the best result, but maintaining a single, coherent environment.
[12:14:32 EDT(-0400)] <colinclark> We would only do this very conservatively...
[12:14:36 EDT(-0400)] <colinclark> as in, when we absolutely must.
[12:14:44 EDT(-0400)] <Bosmo1> Another thing we should mention, is that one of the steps down this pathway, a mixed archicture on the JVM, delivered in THREE languages, represents the ultimate maintenance and debugging nightmare (tongue)
[12:14:50 EDT(-0400)] <Bosmo1> So we should be careful not to go there (tongue)
[12:14:59 EDT(-0400)] <Justin_o> colinclark: i was wondering if this would tie us down to the JVM
[12:15:02 EDT(-0400)] <colinclark> Very, very nightmarish.
[12:15:07 EDT(-0400)] <Bosmo1> Justin_o: Please see my earlier comment (tongue)
[12:15:21 EDT(-0400)] <colinclark> Justin_o: Nicely, it would only tie us down to the JVM for as long as we choose to use Java-based libraries.
[12:15:33 EDT(-0400)] * elicochran (n=elicochr@dhcp-169-229-212-73.LIPS.Berkeley.EDU) has joined #fluid-work
[12:15:38 EDT(-0400)] <colinclark> So here's how I'm imagining the approach:
[12:15:39 EDT(-0400)] <Bosmo1> We should be clear - we never expect any of our clients to ever write any Java code
[12:15:55 EDT(-0400)] <Bosmo1> Or more, for that matter, to configure any Java-specific artefacts, if at all possible
[12:15:55 EDT(-0400)] <colinclark> 1. We'd start with plain old Python and something like CherryPy for WSGI.
[12:16:09 EDT(-0400)] <Bosmo1> I thought for a while about, for example, thinking if we can make sure that a client never has to modify a web.xml file
[12:16:09 EDT(-0400)] <colinclark> 2. We'd build RESTful, JSONic web services.
[12:16:20 EDT(-0400)] <colinclark> As needed, we might decide that the Renderer should be used on the server.
[12:16:37 EDT(-0400)] <colinclark> Then we can easily shift onto the JVM to get access to the underlying RSF library for the Renderer in Java.
[12:16:42 EDT(-0400)] <Bosmo1> Another alternative for CherryPy that I am interested in at the moment is repoze.bfg
[12:16:52 EDT(-0400)] <Bosmo1> But it would probably, in the first pass, just be something we could mine for ideas
[12:16:56 EDT(-0400)] <colinclark> If, at a later date, we find the resources to port the Renderer to Python, then we're flexible again.
[12:17:08 EDT(-0400)] <colinclark> Justin_o: Does that seem reasonable?
[12:17:24 EDT(-0400)] <colinclark> Now's another good moment for questions/comments.
[12:17:25 EDT(-0400)] <Justin_o> colinclark: I see, so we make use of existing libraries and port as needed
[12:17:33 EDT(-0400)] <colinclark> Yep.
[12:17:50 EDT(-0400)] <colinclark> My theory is that we'll find doing all-clientside rendering will be problematic for phones with limited batteries.
[12:17:51 EDT(-0400)] <Bosmo1> We have the overall aim that as far as possible, any coding/modification done by a user is "JSONic"
[12:18:05 EDT(-0400)] <colinclark> And that we'll want to be able to take the same template and component tree and render it on the server instead.
[12:18:14 EDT(-0400)] <Bosmo1> Which commits us to as little as possible, infrastructure and language-wide
[12:18:21 EDT(-0400)] <colinclark> To give the client a head start.
[12:18:32 EDT(-0400)] <Bosmo1> wise
[12:18:38 EDT(-0400)] <colinclark> The PyDev tools for Aptana/Eclipse seem pretty reasonable. I got them up and running in minutes, though I haven't yet used them with Jython.
[12:18:46 EDT(-0400)] <Bosmo1> colinclark: That's cool
[12:18:57 EDT(-0400)] <Bosmo1> It's interesting that Aptana seems to be backing a lot of the same horses as us
[12:19:24 EDT(-0400)] <colinclark> They haven't fully absorbed PyDev, unfortunately.
[12:19:30 EDT(-0400)] <Bosmo1> ?
[12:19:33 EDT(-0400)] <Bosmo1> I heard that they bought it
[12:19:35 EDT(-0400)] <colinclark> Aptana bought the company that makes it last August.
[12:19:38 EDT(-0400)] <Bosmo1> ok
[12:19:43 EDT(-0400)] <colinclark> But they haven't done anything to integrate it into their products.
[12:19:47 EDT(-0400)] <Bosmo1> Well, I'm sure it is only a matter of time
[12:20:01 EDT(-0400)] <colinclark> So it works just fine, but unlike RadRails or something, you can't just download a full IDE and write code.
[12:20:02 EDT(-0400)] <Bosmo1> I doubt they are like Microsoft, and have bought stuff only to crush it
[12:20:05 EDT(-0400)] <colinclark> Hopefully that's true.
[12:20:07 EDT(-0400)] <colinclark> davetrey: You still following? Any comments/questions/etc.?
[12:20:14 EDT(-0400)] <colinclark> This is a good time to lead into a bit of Aptana discussion if you want.
[12:20:21 EDT(-0400)] <colinclark> Or whatever elese.
[12:20:29 EDT(-0400)] <colinclark> Questions/comments from any and all?
[12:21:05 EDT(-0400)] <davetrey> Colin: Yes, I'm here. No questions by now.
[12:21:10 EDT(-0400)] <laurelw> so you said this wasn't the "final decision". are there other ideas out there?
[12:21:28 EDT(-0400)] <Bosmo1> Well... insofar as it is not a "final decision", I think we are going to try to do stuff
[12:21:40 EDT(-0400)] <Bosmo1> We will not try to reach a "final decision" before we start trying to experiment with building an app (tongue)
[12:22:04 EDT(-0400)] <laurelw> makes sense
[12:22:16 EDT(-0400)] <Bosmo1> Other ideas.... not very many other plausible ones
[12:22:27 EDT(-0400)] <Bosmo1> I don't think we are very strongly considering Ruby or PHP right now
[12:22:42 EDT(-0400)] <Bosmo1> Which are the only two other particularly plausible language choices
[12:22:43 EDT(-0400)] <davetrey> Bosmo1: ok. good to know.
[12:22:56 EDT(-0400)] <Bosmo1> Ruby at least could be sensibly deployed on a JVM, PHP would be best not to be
[12:23:33 EDT(-0400)] <colinclark> The core issues here with Ruby and PHP, to summarize:
[12:23:43 EDT(-0400)] <Bosmo1> PHP gets us good access to a wide developer base - but we would not end up using PHP in a way which was "idiomatic"
[12:23:45 EDT(-0400)] <colinclark> Ruby is largely a monoculture centred around Rails.
[12:23:50 EDT(-0400)] <Bosmo1> So our access to that developer base would be largely illusory
[12:23:51 EDT(-0400)] <colinclark> If Rails fits, you're all set.
[12:23:58 EDT(-0400)] <colinclark> If not, there's just not a lot of infrastructure for you.
[12:24:07 EDT(-0400)] <colinclark> Bosmo1 hit the PHP issue nicely.
[12:24:15 EDT(-0400)] <Bosmo1> We would not be writing PHP with code embedded in markup in the traditional way.... which would alienate virtually all PHP developers
[12:24:24 EDT(-0400)] <colinclark> I'm certainly open to other ideas that people might have for us to investigate.
[12:24:42 EDT(-0400)] <colinclark> But we're, luckily, starting to converge on this "flexible" Python approach.
[12:24:47 EDT(-0400)] <colinclark> I mean, to summarize...
[12:24:52 EDT(-0400)] <Bosmo1> Saying we were using PHP might be a good thing at the level of CATTs
[12:25:00 EDT(-0400)] <Justin_o> colinclark: the purpose of the server side is only for mobile devices?
[12:25:01 EDT(-0400)] <Bosmo1> But there is no point setting out to deceive people...
[12:25:05 EDT(-0400)] <colinclark> You can see we've started to establish a set of criteria for us when evaluating technologies.
[12:25:14 EDT(-0400)] <colinclark> And we're also converging on a small set of interesting technologies.
[12:25:25 EDT(-0400)] <colinclark> So Bosmo1 is right that we'll start to build something soon...
[12:25:34 EDT(-0400)] <colinclark> so here's how I'm expecting things will play out over the next couple weeks.
[12:25:44 EDT(-0400)] <Bosmo1> We could discover something completely horrible, when we start to write our first app
[12:25:45 EDT(-0400)] <Bosmo1> Who knkows
[12:25:47 EDT(-0400)] <colinclark> We'll get that criteria into the wiki and out onto the list.
[12:25:59 EDT(-0400)] <colinclark> We'll work with the McCord museum to identify a starting project.
[12:26:15 EDT(-0400)] <colinclark> Hugues Boily there has the ideas of building artifact pages for the McCord collection that will work nicely on a phone.
[12:26:24 EDT(-0400)] <colinclark> michelled will be in Montreal next week to work with Hugues.
[12:26:27 EDT(-0400)] <colinclark> Get the ball rolling.
[12:26:29 EDT(-0400)] <colinclark> Which is cool.
[12:26:42 EDT(-0400)] <colinclark> At that point, I'll draft a proposal to the community about the technology stack we will start with.
[12:27:02 EDT(-0400)] <colinclark> We'll all keep our fingers cross that we don't hit "another Dojo," and that we can move forward with a solution.
[12:27:23 EDT(-0400)] <colinclark> But this flexible approach with Python as a starting point gives us a path to migrate as needed, driven by actual functional needs.
[12:27:27 EDT(-0400)] <colinclark> Does that seem reasonable?
[12:27:53 EDT(-0400)] <laurelw> yes
[12:28:09 EDT(-0400)] <colinclark> y'all?
[12:28:12 EDT(-0400)] <Justin_o> I'm excited to see how this all works
[12:28:16 EDT(-0400)] <davetrey> yepp
[12:28:42 EDT(-0400)] <michelled> sounds good
[12:28:51 EDT(-0400)] <colinclark> Ok, great.
[12:29:05 EDT(-0400)] <colinclark> So any questions/comments/etc. before we all go back to what we were doing?
[12:29:25 EDT(-0400)] <colinclark> To reiterate, this process is open: if you want to get involved more, share your ideas, etc, please dive in.
[12:29:39 EDT(-0400)] <colinclark> Otherwise, we'll continue to have these chats, build up some documentation the wiki, and keep moving forward.
[12:29:58 EDT(-0400)] <colinclark> Thanks, everyone!
[12:30:07 EDT(-0400)] <Bosmo1> I wanted to talk a bit about focus
[12:30:12 EDT(-0400)] <colinclark> Chatting is less cool than talking, but this is (in a way) more reliable than Breeze.
[12:30:14 EDT(-0400)] <Bosmo1> If we have disbanded that "old meeting"
[12:30:23 EDT(-0400)] <colinclark> At least we can all perceive each other. (wink)
[12:30:30 EDT(-0400)] <colinclark> Bosmo1: I think we're not Officially Disbanded.
[12:30:50 EDT(-0400)] * anastasiac is glad this meeting was logged, so she can catch up later
[12:32:19 EDT(-0400)] * jessm too
[12:33:27 EDT(-0400)] * colinclark too.
[12:33:36 EDT(-0400)] <colinclark> It's slower and more work to type, but pretty good.
[12:34:46 EDT(-0400)] * elicochran (n=elicochr@dwin-wlan-164.AirBears.Berkeley.EDU) has joined #fluid-work
[12:43:01 EDT(-0400)] * laurelw (n=Laurel@142.150.154.178) has left #fluid-work
[12:43:03 EDT(-0400)] * laurelw (n=Laurel@142.150.154.178) has joined #fluid-work
[12:43:28 EDT(-0400)] * laurelw (n=Laurel@142.150.154.178) has left #fluid-work
[12:43:29 EDT(-0400)] * laurelw (n=Laurel@142.150.154.178) has joined #fluid-work
[12:43:41 EDT(-0400)] * laurelw (n=Laurel@142.150.154.178) has left #fluid-work
[12:44:03 EDT(-0400)] * laurelw (n=Laurel@142.150.154.178) has joined #fluid-work
[12:49:00 EDT(-0400)] <Bosmo1> I still want to talk about focus
[12:49:06 EDT(-0400)] <Bosmo1> Once there is anyone around again
[12:49:33 EDT(-0400)] <yura> this could be interesting to look at : http://pylonshq.com/
[12:54:46 EDT(-0400)] <jsilvaa> so... I am trying ui-options on the atrcdev site (http://atrcdev.atrc.utoronto.ca/) but I lost the open/close button. Any ideas where it went?
[13:02:13 EDT(-0400)] <Bosmo1> yura: Yes, pylons is another one that we have generally taken in.... it is a kind of "semi-peer" to CherryPy, but is at a different aggregation level
[13:02:35 EDT(-0400)] <Bosmo1> CherryPy is really "foundational" in that in some senses it is not really a complete framework - which is reasonable attractive to us
[13:02:50 EDT(-0400)] <Bosmo1> For example, TurboGears uses CherryPy, in the same sort of way that Pylons uses Route
[13:03:06 EDT(-0400)] <Bosmo1> Although "Route" is even less of a framework than CherryPy is....
[13:04:16 EDT(-0400)] <jamon> turbo gears isn't a very good framework
[13:04:22 EDT(-0400)] <jamon> it's too haphazardly stuck together
[13:05:51 EDT(-0400)] <Justin_o> michelled, laurelw: jsilvaa had a ui options question above
[13:08:29 EDT(-0400)] <michelled> jsilvaa: what do you mean the open/close button? do you mean the close of the dialog?
[13:08:46 EDT(-0400)] <Bosmo1> We are quite interested in frameworks which are simply "foundational"
[13:08:58 EDT(-0400)] <Bosmo1> Since we have too many of our own ideas on issues like i) persistence, ii) how markup is generated
[13:09:15 EDT(-0400)] <Bosmo1> For a start, merely using CouchDB would confuse the idiom of a lot of the "full stack" frameworks
[13:09:45 EDT(-0400)] <Bosmo1> We really want a system which takes care of i) request dispatching and namespacing, ii) URL mapping, and iii) very little else
[13:10:23 EDT(-0400)] <Bosmo1> Anything which has developed too much of what it likes to call an "MVC structure" is probably already at too high a level of abstraction
[13:10:36 EDT(-0400)] <Bosmo1> repoze.bfg is interesting, because it is unique in having something like the same concept of a "model" as us
[13:10:40 EDT(-0400)] <Bosmo1> But i haven't looked too much into it
[13:11:44 EDT(-0400)] <jamon> sounds like a tenuous gray area between writing something from the ground up, or hacking on an existing framework
[13:12:09 EDT(-0400)] <Bosmo1> CherryPy seems fairly cool in terms of a match between what we want done, and the features it provides
[13:12:16 EDT(-0400)] <Bosmo1> It really doesn't do very much other than operating a container idiom
[13:15:33 EDT(-0400)] <jamon> does cherrypy allow using more than 1 db engine? http://pylonshq.com/docs/en/0.9.7/models/#multiple-engines
[13:15:54 EDT(-0400)] <Bosmo1> CherryPy has no concept of a "db engine"
[13:15:55 EDT(-0400)] <Bosmo1> (smile)
[13:16:04 EDT(-0400)] <jamon> all very interesting stuff, i'll have to play some more
[13:16:21 EDT(-0400)] <Bosmo1> What you do after your request is routed to you is entirely up to you...
[13:16:44 EDT(-0400)] <Bosmo1> It's precisely its lack of concept of an engine which makes it attractive
[13:17:47 EDT(-0400)] <jamon> so, but any controller can route a request to wherever you like no?
[13:18:50 EDT(-0400)] <Bosmo1> Yes
[13:19:01 EDT(-0400)] <Bosmo1> if we used Pylons, we would naturally have to neglect some parts of it
[13:20:39 EDT(-0400)] <Bosmo1> "class HelloController(BaseController):"
[13:20:46 EDT(-0400)] <Bosmo1> This sort of thing, to me, represents a bad smell (tongue)
[13:21:04 EDT(-0400)] <Bosmo1> But this is a very vague issue, that we could debate endlessly...
[13:21:17 EDT(-0400)] <jamon> i guess the reason i think of pylons first is a friend of mine, mike fletcher, http://www.vrplumber.com/programming/
[13:21:31 EDT(-0400)] <jamon> he's moved things from django, turbogears, to pylons
[13:21:57 EDT(-0400)] <Bosmo1> Ah, "Twisted" seems very interesting
[13:22:05 EDT(-0400)] <Bosmo1> I read about this pointed to from the WSGI docs
[13:22:15 EDT(-0400)] <Bosmo1> But I am not sure if it is possible to support on the JVM concurrency model
[13:22:17 EDT(-0400)] <jamon> i really don't have enough information, but i trust his expertise sinc ehe pretty much tought me python
[13:23:17 EDT(-0400)] <Bosmo1> This page you have mentioned talks mainly about Twisted, not Pylons (tongue)
[13:23:37 EDT(-0400)] <jamon> yeah he hasn't updated much, it's an appeal to authority
[13:23:42 EDT(-0400)] <jamon> also, http://wiki.pylonshq.com/display/pylonscookbook/Pylons+on+Jython
[13:24:02 EDT(-0400)] <Bosmo1> Yeah, Pylons is fairly traditional and should be no problem to support
[13:24:19 EDT(-0400)] <Bosmo1> I believe that "any" WSGI-based framework that doesn't make esoteric concurrency demands should work on Jython
[13:24:53 EDT(-0400)] <jamon> yeah, cherrypy supposedly works to: http://henkenotes.blogspot.com/2007/09/cherrypy-3-jython-third-attempt.html
[13:25:25 EDT(-0400)] <Bosmo1> I have heard good things about Pylons too
[13:25:32 EDT(-0400)] <Bosmo1> I am just concerned that it might "do too much"
[13:26:14 EDT(-0400)] <jamon> concern with pylons would also be how long it has been around and the community around it
[13:26:35 EDT(-0400)] <Bosmo1> CherryPy has minimal functionality, and that functionality has been beaten on for many years
[13:26:48 EDT(-0400)] <jamon> cherrypy seems to have been around a few years longer than most though
[13:27:04 EDT(-0400)] <Bosmo1> Another interesting direction from CherryPy is to hop to "SpringPython"
[13:27:28 EDT(-0400)] <Bosmo1> A friend send me this interesting (and biased) comparison of Python frameworks
[13:27:28 EDT(-0400)] <Bosmo1> http://mdp.cti.depaul.edu/examples/static/web2py_vs_others.pdf
[13:27:33 EDT(-0400)] <Bosmo1> I meant to post it up to the wiki
[13:27:45 EDT(-0400)] <Bosmo1> Although it is from the web2py author, it covers a lot of objective ground
[13:29:43 EDT(-0400)] <alisonbenjamin> i made a patch to address http://issues.fluidproject.org/browse/FLUID-2399 . it's posted on the jira. i don't have commit access so if someone could have a look that would be great.
[13:49:56 EDT(-0400)] <Bosmo1> anastasiac: Are you there, as a CATT?
[13:50:07 EDT(-0400)] <anastasiac> I am indeed
[13:55:50 EDT(-0400)] <Bosmo1> We are having a Col-lection-Space chat
[13:56:03 EDT(-0400)] <Bosmo1> About this thing which has uneuphoniously come to be named, "the schema"
[14:00:48 EDT(-0400)] * yura (n=yura@142.150.82.64) has joined #fluid-work
[14:02:31 EDT(-0400)] <Bosmo1> So, we need an extension
[14:02:41 EDT(-0400)] <Bosmo1> To be able to issue a directive from the server for inclusion of a .js file
[14:18:48 EDT(-0400)] <anastasiac> Bosmo1 - sorry, missed your messages
[14:18:54 EDT(-0400)] <anastasiac> who is chatting?
[14:23:10 EDT(-0400)] <Bosmo1> Dan, and Carl
[14:23:14 EDT(-0400)] <Bosmo1> And, I guess, me
[14:23:20 EDT(-0400)] <anastasiac> ah
[14:23:25 EDT(-0400)] <Bosmo1> So, Nico has a few lines of code which does this
[14:23:32 EDT(-0400)] <Bosmo1> Which we should probably package as some kind of plugin
[14:23:38 EDT(-0400)] <anastasiac> perhaps we should all jump in the #collectionspace channel and chat there
[14:23:41 EDT(-0400)] <Bosmo1> But this will also require an extension to this thing, which we call, "the schema"
[14:23:44 EDT(-0400)] <Bosmo1> They are currently hiding
[14:23:50 EDT(-0400)] <Bosmo1> I am just here to relay their emissions
[14:24:13 EDT(-0400)] <anastasiac> regarding an extension to the 'schema':
[14:24:32 EDT(-0400)] <anastasiac> this thing is constantly evolving, so I wouldn't even consider it an extention
[14:24:39 EDT(-0400)] <anastasiac> I'd consider it a refinement
[14:27:56 EDT(-0400)] <anastasiac> none of this is written in stone
[14:30:38 EDT(-0400)] <Bosmo1> Dan says he now has questions
[14:30:41 EDT(-0400)] <Bosmo1> but coherent questions (tongue)
[14:30:50 EDT(-0400)] <Bosmo1> They have been off in the back room drawing "swim lanes"
[14:31:14 EDT(-0400)] <anastasiac> excellent! Tell them to take a picture and post it (smile)
[14:31:22 EDT(-0400)] <anastasiac> questions are good
[14:45:40 EDT(-0400)] <Bosmo1> Yes
[14:45:43 EDT(-0400)] <Bosmo1> They have a picture now
[14:53:46 EDT(-0400)] <michelled> alisonbenjamin: I'll take a look at your patch
[14:54:01 EDT(-0400)] <alisonbenjamin> it's tiny. thanks.
[15:57:49 EDT(-0400)] <anastasiac> michelled, you there?
[15:58:14 EDT(-0400)] <michelled> yup
[15:58:41 EDT(-0400)] <anastasiac> can I ask you a very specific question about some specific code inside UIOptions.js?
[15:58:46 EDT(-0400)] <anastasiac> to make sure I understand something?
[15:58:49 EDT(-0400)] <michelled> sure
[15:59:11 EDT(-0400)] <anastasiac> inside createRenderOptions(), at line 249 in my version of the code
[15:59:27 EDT(-0400)] <anastasiac> the aggregate model, the second thing, labelMap
[15:59:34 EDT(-0400)] <anastasiac> it doesn't have an applier, right?
[15:59:47 EDT(-0400)] <anastasiac> just a model?
[16:00:31 EDT(-0400)] * anastasiac is learning about the ChangeApplier
[16:00:33 EDT(-0400)] <michelled> seems like it does have an applier given the return statement below
[16:00:52 EDT(-0400)] <michelled> I didn't actually write that part of the code - Bosmo1 did
[16:01:01 EDT(-0400)] <anastasiac> no, that's the composite applier, isn't it?
[16:01:23 EDT(-0400)] <anastasiac> that was part of my question: what does the composite applier do with a sub-model that doesn't have an applier
[16:01:36 EDT(-0400)] <anastasiac> ah, ok, so I could ask him
[16:02:20 EDT(-0400)] <michelled> if you look at the implementation of fluid.assembleModel it seems to be creating an applier and attaching it to the model
[16:02:33 EDT(-0400)] <michelled> that it returns
[16:02:36 EDT(-0400)] <anastasiac> ah, hm... interesting...
[16:02:48 EDT(-0400)] <michelled> meaning, an applier is an integral part of a model
[16:03:49 EDT(-0400)] <anastasiac> ah, but it looks like assembleModel includes any sub-appliers that are passed to it, but doesn't create missing ones
[16:04:07 EDT(-0400)] <anastasiac> wait, I take that back
[16:04:24 EDT(-0400)] <anastasiac> that happens in attachModel()
[16:05:10 EDT(-0400)] <anastasiac> ok, cool, this was helpful
[16:05:24 EDT(-0400)] <michelled> np
[16:05:25 EDT(-0400)] <anastasiac> I'll probably actually step through this, just to confirm my understanding
[16:05:51 EDT(-0400)] <anastasiac> btw, I was wrong - no applier is created
[16:05:54 EDT(-0400)] <anastasiac> a model is created
[16:06:10 EDT(-0400)] <anastasiac> if (rec.applier) {
[16:06:10 EDT(-0400)] <anastasiac> superApplier.addSubApplier(path, rec.applier);
[16:06:10 EDT(-0400)] <anastasiac> }
[16:32:21 EDT(-0400)] * laurelw (n=Laurel@142.150.154.178) has left #fluid-work
[17:22:54 EDT(-0400)] * anastasiac (n=stasia@142.150.154.189) has left #fluid-work
[17:36:58 EDT(-0400)] * apetro (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined #fluid-work
[17:37:52 EDT(-0400)] * clown (n=clown@142.150.154.101) has left #fluid-work
[17:45:02 EDT(-0400)] * Bosmo1 (n=Antranig@ginger.caret.cam.ac.uk) has joined #fluid-work
[20:08:04 EDT(-0400)] * alisonbenjamin (n=alisonbe@dsl-207-112-55-141.tor.primus.ca) has joined #fluid-work