Wiki Code Docs Demo

Ringobot log - RingoJS IRC channel: #ringojs on irc.freenode.net

2010-05-10:

[2:42] <oravecz> the wiki (http://ringojs.org/wiki/request_dispatching/) talks about three ways to handle argument passing, but the docs are TBD. Are any of these implemented?
[7:07] <hannesw> markdown links are not working on this page:
[7:07] <hannesw> http://ringojs.org/demo/mount/point/
[7:07] <hannesw> any idea?
[7:16] <hannesw> i updated everything, now it's working again.
[8:03] <gmosx> g'morning
[8:03] <hannesw> good morning
[8:28] <robi42> http://log.robert42.com/ :)
[8:32] <oberhamsi> uh sweet with integrated disqus :)
[8:37] <hannesw> and blink!
[10:27] * robi42_ curious when live-operational troubles/bugs will show up on log.robert42.com :)
[12:40] <hannesw> mysterious performance problem solved:
[12:40] <hannesw> it was the number of jetty acceptors
[12:40] <hannesw> in jetty.xml
[12:55] <oberhamsi> what was the problem? slowness?
[12:56] <oberhamsi> i tried 7.0.2 for a while, should be smooth upgrade if we want it
[12:56] <oberhamsi> oh it already is updated :)
[13:10] <hannesw> it's updated in my repo
[13:10] <hannesw> that's why i did the benchmarking
[13:10] <hannesw> will push to ringo/master soon
[13:10] <hannesw> the acceeptors thing is really mainly a benchmark issue
[13:11] <hannesw> if you have many short-lived connection requests, 2 acceptors can't cope
[13:11] <hannesw> just talked with greg wilkins about it
[13:13] <oberhamsi> alright, interesting
[13:14] <hannesw> he says more acceptors may also tickle NIO bugs
[13:15] <hannesw> "rule of thumb is set to to at least the number of CPUs that you have if you have a lot of short connections, then I'd double it so 8 on a 4 core machine etc."
[13:16] <hannesw> now I'm trying to get good benchmark behaviour using 4 acceptors, if I can't then i'll probably set it to 8.
[13:17] <oberhamsi> i see
[13:23] <oberhamsi> the new jsgi async: i don't get how i write in async scenario? that was onProgress before. do you have example?
[14:17] <hannesw> oberhamsi: you just resolve to a jsgi response
[14:17] <hannesw> there's no support for single (unbuffered) writes
[14:17] <hannesw> so it's like jsgi, only asynchronous
[14:20] <oberhamsi> hm, i'm not sure i get it
[14:21] <oberhamsi> ah okay, i return a normal jsgi response.. just later
[14:22] <oberhamsi> still not sure how code for that would look like.
[14:23] <oberhamsi> especially because i get suspended in handleAsyncResponse, so another request would have wake me up?
[14:24] <hannesw> that's one typical scenario for async jsgi
[14:25] <oberhamsi> alright, then i get it :)
[14:25] <hannesw> http://gist.github.com/379761
[14:25] <hannesw> this is how it would look
[14:26] <hannesw> with ringo/promise
[14:26] * oberhamsi trying it out
[14:27] <hannesw> i just added the missing require("ringo/promise")
[14:34] <oberhamsi> yep works.
[14:34] <oberhamsi> i used the single writes only for unittests, so i don't miss the much
[15:28] <ringostarr> c5490a0 Hannes Walln?fer: update jetty libs to 7.0.2
[18:07] <oberhams> do we wanna meet today? i'd have topics but nothing urgent and am low on battery lol
[18:08] <hannesw_> I'm here
[18:08] <earl> me too
[18:08] <robi42> me too
[18:09] <oberhams> oh and we sched release for this wednesday :)
[18:09] <hannesw_> yep
[18:09] <robi42> so, release upcoming on wedn., yep :)
[18:10] <earl> i don't have anything to discuss, except maybe some release planning (do we want to do a 0.5 in 2 days? if so, what scope?)
[18:10] <earl> ... +1 :)
[18:11] <hannesw_> i'm all for releasing more often
[18:11] <robi42> i'm all +1 for 0.5 on wedn., too :)
[18:11] <oberhams> well what i can tell nothing is broken and we made a lot from the roadmap. so +1 release
[18:11] <hannesw> and i'll try to stuff my encoding/io/process patch into it :)
[18:11] <oberhams> hehe
[18:13] <oberhams> i put storage stuff on agenda, but not much too discuss... zero code yet
[18:17] <robi42> would be nice to have (count(), iterator())
[18:18] <hannesw> robi42: yes. is that easy to implement in ringo-hibernate?
[18:18] <robi42> both easy
[18:18] <hannesw> cool
[18:18] <hannesw> i'd just say go ahead
[18:19] <robi42> in berkeley db?
[18:19] <robi42> hard there?
[18:19] <hannesw> I'll try to follow you with berkeleydb and googlestore
[18:19] <hannesw> no, i don't think it will be hard
[18:19] <robi42> ok, what about the slightly differing orderBy()
[18:19] <oberhams> i could do smth for berkeley
[18:19] <hannesw> actually the whole berkekelydb code is up for some refactoring
[18:19] <hannesw> oberhams ++
[18:19] <hannesw> having some help with berkeley would be great
[18:20] <oberhams> sure, by now i know my way around it
[18:20] <robi42> am mainly occupied with hibernate already, but will have a look at berkeley as well, of course
[18:22] <robi42> so, orderBy('propertyName', 'desc') or orderBy('propertyName desc')? :)
[18:23] <hannesw> i'm fine with either
[18:23] <robi42> other opinions?
[18:24] <robi42> oberhams, earl?
[18:24] <oberhams> hm, both look good. rather the first.. gut feel
[18:24] <earl> would prefer the latter. if the formen, then with an enum instead of a string
[18:25] <robi42> ok. enum in which way?
[18:25] <earl> is order by supposed to take multiple propnames as well?
[18:26] <robi42> it's chainable
[18:27] <robi42> as in Foo.query().orderBy('bar').orderBy('baz').select()
[18:28] <earl> and that's intended to give the usual lexicographical product sorting order?
[18:29] <earl> i.e. sorting by bar takes precendence, sorting by baz is only applicable for objects which have the same bars?
[18:29] <robi42> yes
[18:29] <earl> then i'd simply go for two separate sorting methods
[18:30] <earl> asc() and desc()
[18:30] <earl> or orderAsc() and orderDesc() if you want to be more verbose
[18:30] <robi42> sounds good to me
[18:31] <hannesw> sounds very bad to me :)
[18:31] <robi42> why? :)
[18:32] <oberhams> hm parameterized order is nicer, no?
[18:32] <hannesw> because i prefer what we currently have
[18:32] <oberhams> django does .order('-field') for desc, but that was invisible in code
[18:33] <hannesw> what do you mean by "invisible in code"?
[18:33] <oberhams> you can overlook it easily
[18:33] <robi42> also google datastore api allows `-` for desc ordering, btw
[18:34] <hannesw> robi42 really?
[18:34] <robi42> yep
[18:34] <oberhams> hm not so exotic afterall
[18:34] <hannesw> well fine with me
[18:34] <oberhams> robi42, you must decide yourself :)
[18:35] <robi42> well, i like orderBy('prop[ desc]') :)
[18:35] <earl> i've just a big dislike of magic string constants (as we have currently in googlestore)
[18:36] <robi42> which magic string constants?
[18:37] <hannesw> "asc" and "desc"
[18:37] <earl> orderBy('foo', 'desc')
[18:38] <hannesw> well we can try the "-prop" thing
[18:38] <robi42> alright
[18:38] <hannesw> we could also use -1 or 1 imo
[18:38] <earl> yuck, even more ugly
[18:38] <hannesw> let's try different things
[18:39] <earl> why not export ASC/DESC enums?
[18:39] <hannesw> what enums? those would be numbers, right?
[18:39] <robi42> orderBy('prop', DESC) ?
[18:39] <earl> nope, object()s
[18:40] <earl> but that's an impl detail
[18:40] <hannesw> better use numbers because they'll work across reloads
[18:41] <earl> even more of an impl detail :)
[18:41] <hannesw> work vs non-work is not an impl detail
[18:42] <earl> but a good point, even though i don't think reloading of the storage module is really an issue
[18:44] <oberhams> ASC/DESC sounds good
[18:44] <hannesw> i think i prefer plain strings to exported values
[18:45] <earl> because they are longer _and_ induce more errors?
[18:45] <hannesw> they are not longer, and you have to be pretty stupid to get them wrong
[18:45] <earl> len("'asc'") > len("ASC")
[18:46] <earl> and stupidity is in the eye of the beholder
[18:46] <hannesw> yeah, but you have to import ASC, don't you?
[18:46] <earl> your IDE will only tell you a string param is required and won't autocomplete
[18:46] <earl> but i'll stop here, as i find that discussion mildly irritating :)
[18:47] <hannesw> your ide tells you about the type of js function parameters?
[18:48] <earl> forget it
[18:48] <hannesw> let's just try what works best.
[18:48] <hannesw> ok?
[18:48] <robi42> i'm actually pro exported values but fine with plain strings in this case, too :)
[18:48] <earl> i think i'm just not sufficiently convinced we have o redo well-known mistakes on our own
[18:51] <hannesw> earl: i don't think this is a mistake. I prefer strings to enums most of the time
[18:51] <earl> well, that's a bad preference, then
[18:51] <hannesw> why? I was talking about an API user, not an API designer
[18:52] <earl> self-documenting apis must be bad, i guess
[18:53] <earl> i prefer enums in APIs that use enums
[18:54] <earl> and DSLs if the API actually wants to expose a DSL
[18:54] <earl> '[-]propName' is a sensisble micro-dsl, imho
[18:54] <earl> ('propName', 'desc') is a magic string constant that wants to be an enum
[18:55] <earl> 'propName[ desc]' is another micro-dsl
[18:55] <hannesw> for example, look at this:
[18:55] <hannesw> http://github.com/hns/ringo-cometd/blob/master/lib/ringo/cometd.js#L126
[18:55] <hannesw> i totally prefer getAttribute("org.cometd.bayeux")
[18:56] <earl> apples and oranges
[18:56] <hannesw> to getAttribute(org.cometd.Bayeux.ATTRIBUTE)
[18:57] <earl> how about cx.org.cometd.bayeux?
[18:57] <hannesw> why
[18:57] <hannesw> away for a few minuts...
[18:57] <earl> or getBayeux(cx) ?
[18:58] <earl> (which won't work in this example, as there's already a getBayeux defined)
[18:58] <oberhams> in your terms django has similar query api and has micro dsl
[18:58] <oberhams> '-field', '?' (rndom) 'post__author__name' and such
[18:59] <robi42> (adding an import like `var {ATTRIBUTE} = require('org.cometd.Bayeux');` is hassle-free enough, imho)
[18:59] <robi42> so let's give '[-]prop' a try?
[18:59] <hannesw> fine with me
[19:00] <oberhams> okay
[19:00] <earl> the getAttribute is actually a pretty good example of all that's bad about string constants
[19:00] <earl> assume bayeux moves to apache, package and keys rename to org.apache
[19:00] <earl> then you are just plain lucky that intellij also searches strings and comments when doing the accodring refactoring
[19:01] <earl> wouldn't be an issue if someone had designed a sensible api in the first place ...
[19:02] <hannesw> should we talk about the first agenda item?
[19:02] <hannesw> I'd very much like to talk about rhino-opt :)
[19:02] <robi42> please! :)
[19:02] <earl> then go ahead and talk about it
[19:02] <oberhams> haha yes
[19:03] <hannesw> well i've made a lot of benchmarking recently
[19:03] <hannesw> and the picture is:
[19:04] <hannesw> rhino _is_ slow, and that's a problem
[19:04] <hannesw> but it's not a problem for ordinary web apps
[19:04] <hannesw> not at all, actually
[19:04] <earl> slow compared to?
[19:04] <hannesw> node.js
[19:04] <earl> so ringo is slow?
[19:04] <olegp> quick q: is there no way to do synchronous http requests with httpclient?
[19:05] <hannesw> olegp: yep, sync actually the default
[19:05] <oberhams> olegp, yes default sync
[19:05] <olegp> so if I omit success, the return value is the result?
[19:06] <oberhams> maybe that's not obvious b/c of all the callbacks in signature. but all request methods return an Exchange
[19:06] <oberhams> olegp, yes. you don't have to omit callback.. that's a bit strange
[19:06] <hannesw> so, i think the message needs to be two way:
[19:06] <hannesw> for normal web apps, ringo/rhino scales very well, and can compete with node
[19:07] <hannesw> and for js-intensive stuff, rhino has its problems, but i'm working on that
[19:07] <robi42> how'd you define normal web apps?
[19:07] <hannesw> because the rhino-opt thing is looking pretty good
[19:07] <hannesw> robi42: not doing too much in js :)
[19:08] <robi42> :)
[19:08] <hannesw> so where we currently hit our limits is with doing a lot in js
[19:08] <robi42> like some rather heavy computation stuff and such?
[19:08] <hannesw> or just calling a lot of java methods back and forth, e.g. processing
[19:09] <oberhams> yes, not sure i get what you mean with lot in js. don't we plan on doing even more in js? skins..
[19:09] <hannesw> yes, we do
[19:09] <hannesw> but skins use binaries and binaries are native host objects, so it'll fly
[19:09] <hannesw> for example, our file upload parser does > 40 mb/sec, which is quite good
[19:10] <oberhams> can you compare to helma?
[19:10] <hannesw> the thing is: what we currently do in ringo is pretty well optimized
[19:11] <hannesw> I'm now starting to do even more in js, knowing that rhino will get faster soon
[19:11] <hannesw> for example: http://gist.github.com/390702#file_results.txt
[19:12] <olegp> Ive played a bunch with different server side js frameworks, and what I like best about ringo is that its possible to wrap around existing Java libs
[19:12] <hannesw> this is stable now, passes all ringo tests, only problem that still needs checking is eval()
[19:12] <robi42> great
[19:12] <hannesw> olegp: yes, that's a killer feature
[19:12] <olegp> so for example rather than having to implement a thrift interface in js, I can get up and running quickly by wrapping around the hector lib for talking to cassandra
[19:13] <olegp> same for sending email, etc
[19:13] <oberhams> hannesw, very nice and that boost just from your recent perf work?
[19:13] <oberhams> "just"
[19:13] <olegp> so actually, its possible to be up and running much faster in ringo than in node, in my opinion
[19:13] <robi42> olegp, full ack
[19:13] <hannesw> well, that's just a very specialized optimization that only applies to closures (functions within functions)
[19:13] <earl> esp as ringo has a webapp framework, and node does not
[19:14] <robi42> and esp as ringo's web framework rocks :)
[19:14] <earl> that's not an issue in a division by zero :)
[19:14] <robi42> :)
[19:14] <oberhams> there is this express framework for node, but it does near nothing
[19:15] <olegp> thats not a killer feature for me tbh, as Im rolling my own on top of mustache, but I can see it being important to a lot of others
[19:15] <hannesw> so I'm planning to do the same for various other areas, such as object literals, constructor functions, global scope, std object protos
[19:15] <hannesw> and of course the other area for optimization is js -> java calling
[19:15] <hannesw> and i think that can be optimized as well
[19:16] <robi42> which would be important also for hibernate, e.g.
[19:16] <hannesw> right, and all other java wrapping libraries
[19:17] <oberhams> i like that it gets faster, good for PR. but for average CMS it probably doesn't matter and we should tell
[19:17] <hannesw> right. it does make a difference, but not that much
[19:17] <hannesw> you only feel the difference if you actually do more in js
[19:17] <hannesw> and it'll be nice to be able to do that
[19:17] <oberhams> yes! +1
[19:18] <olegp> what about the direction of allowing for app code to be written and modified from within a ringo webapp itself
[19:18] <olegp> the way appjet used to do it & akshell does now
[19:19] <olegp> think that could be quite useful, since I tend to work from a lot of different machines, and a browser based ide and env running on my linode or something would be really useful
[19:19] <hannesw> hm, i have a prototype for a browser based ide
[19:19] <olegp> I know you do, I saw the video a while back ;)
[19:19] <olegp> iirc that is
[19:20] <hannesw> i had some plans with it, but gave up (too little time)
[19:20] <hannesw> so I'm planning to open source it
[19:20] <olegp> ok
[19:20] <hannesw> well, don't expect too much
[19:20] <hannesw> i had really forgotten about it.
[19:22] <hannesw> i think I can make the repository public soon (just want to go over it once more)
[19:22] <olegp> nice, that would be very cool
[19:22] <hannesw> would be great if somebody picked it up
[19:23] <hannesw> btw, didn't now about akshell
[19:23] <olegp> I have this feeling that development within the browser is the future: some sort of a mix between github + appjet (so the code repository also provides a runtime)
[19:23] <olegp> yeah .. its fairly recent
[19:24] <olegp> runs on v8
[19:24] <hannesw> yes, i a also think some kind of git behind it would be good
[19:26] <earl> and http://gpl.internetconnection.net/vi/ as a frontend :)
[19:30] <earl> sorry to be a pita about this, but after realizing that we currently have all filters in the datastore query api exposed as methods, i _really_ think dedicated asc/desc methods are the way to go
[19:32] <olegp> akshell has a pretty comprehensive db layer btw: http://www.akshell.com/docs/ref/core/db/
[19:36] <oberhams> olegp, where did you learn about akshell? or just found it?
[19:36] <olegp> news.ycombinator.com
[19:36] <oberhams> ok
[19:37] <olegp> been helping anton promote it a bit & also make it commonjs/jsgi compliant
[19:38] <olegp> its nice for prototyping and api mashups, because of the in browser editor + runtime
[19:38] <olegp> but for anything more serious, ringo is the way forward imo
[19:39] <hannesw> well, akshell does look nice
[19:39] <oberhams> it does indeed
[19:40] <hannesw> have to give it a spin
[19:40] * oberhams battery down... cu tomorrow.. good meet :)
[19:42] <hannesw> by oberhams!
[19:42] <robi42> bye oberhams
[19:42] <olegp> see ya!
[19:42] <robi42> akshell looks interesting at a first glance
[19:43] <hannesw> cu olegp
[19:43] <olegp> Im not off yet ;)
[19:43] <hannesw> ah, ok :)
[19:44] <hannesw> well, what else should we talk about?
[19:44] <hannesw> btw, earl, thanks a lot for documenting fs module
[19:44] <olegp> whats neat about akshell when compared to say appjet or appengine, is that its possible to have modules which provide shared storage to users
[19:44] <earl> (you're welcome)
[19:44] <olegp> so you can have a per user data store, that multiple apps can access
[19:45] <robi42> nice
[19:45] <olegp> I think thats kind of a big deal
[19:46] <hannesw> it is.
[19:46] <robi42> olegp, how do you like ringo's storage api so far?
[19:46] <hannesw> i've thought about this a bit, and i think i'd use cassandra if i were to do something like this
[19:48] <olegp> robi42, its nice, the hibernate module is a lifesaver for me, since I was gonna write a wrapper around jdbc myself, which wouldve taken up a lot of time
[19:48] <hannesw> olegp glad you found ringo-hibernate
[19:48] <olegp> foreign key constraints and associations would be nice, but on second thought I think keeping it simple and providing multiple backends is more valuable
[19:49] <robi42> possibly
[19:49] <robi42> but we really need to introduce associations/references in hibernate wrapper as well
[19:49] <robi42> a convenient way to work with them, that is
[19:50] <robi42> thought about going somewhere reasonably similar to how grails' gorm does it
[19:51] <olegp> also maybe a simpler key value store module, which uses the storage modules under the hood, would be nice for people starting out
[19:51] <olegp> it could also take care of serializing values to json etc
[19:51] <robi42> there's berkeleystore
[19:51] <robi42> and bundled filestore
[19:52] <hannesw> robi42 the problem with references is primarily finding a naming convention?
[19:52] <robi42> also
[19:53] <robi42> am unsure about the api design
[19:53] <robi42> too many options :)
[19:54] <hannesw> maybe don't wait for the perfect solution, just try something
[19:54] <robi42> yep, makes sense; i'll just go ahead then
[19:55] <olegp> btw, a useful page on the wiki would be a list of ringojs compatible commonjs packages and their github links
[19:56] <robi42> btw, we'll do somewhat similar "promotion" like with 0.4 this time?
[19:56] <hannesw> olegp: agreed.
[19:57] <hannesw> btw, feel free to start any page you think is missing
[19:57] <olegp> ok will do
[19:57] <hannesw> great!
[19:58] <hannesw> robi42: ringolog berkeley now works for me (didn't change anything)
[19:58] <hannesw> and it feels great!
[19:58] <robi42> good to know :)
[19:58] <hannesw> are you planning to use it?
[19:58] <robi42> berkeley version misses lots of recent stuff, tho
[19:58] <robi42> maybe
[19:59] <robi42> at first it was my preferred choice
[19:59] <robi42> but then i really needed range queries :)
[19:59] <hannesw> ok, time to implement them in berkeley :)
[20:00] <robi42> migrating the data from mysql to bdb shouldn't be that hard
[20:00] <robi42> on my live instance, i mean
[20:01] <robi42> maybe it's also time for some nice data migration interface :)
[20:04] <robi42> (whereas, simply accessing resp. stores via storage api should actually be convenient enough already, i guess)
[20:05] <olegp> oh, one question I had was: is there an admin command to package up my ringojs app up as a WAR ?
[20:06] <hannesw> not yet
[20:07] <hannesw> i think the closest thing we have to that is ringo-admin create -a
[20:07] <robi42> would it be hard to package a ringo app as .war?
[20:07] <hannesw> which creates a google app enginge application, which uses the java web app layout
[20:07] <hannesw> no, i don't think so
[20:08] <olegp> I did by hand a while back, when it was still called helmang
[20:08] <robi42> guess quite some people would like that
[20:08] <olegp> ran into some issues with a missing trailing slash inside the servlet
[20:08] <hannesw> actually what ringo-admin create -a creates should run on any servlet container i think
[20:08] <olegp> so had to patch up the helmang servlet code
[20:08] <olegp> ok, let me test that :)
[20:10] <robi42> imho, it would be really good to have a (more) compelling general story (for ringo)
[20:10] <hannesw> what do you mean by "general story"?
[20:11] <olegp> ok, so this doesnt quite do what I want
[20:11] <olegp> it sets up a project with web inf etc
[20:11] <robi42> well, currently node.js is somewhat the poster child
[20:11] <robi42> and people at first ask themselves why should i use ringo then?
[20:11] <olegp> I actually like the default layout for dev
[20:12] <olegp> but do want to package it up as a war for deployment
[20:12] <olegp> so maybe I should write that
[20:12] <hannesw> well i think to build a .war you have to use the WEB-INF and everything, don't you?
[20:12] <olegp> (once Ive finished the app itself that is)
[20:12] <hannesw> would be great!
[20:13] <olegp> yeah, so the script should create a temp dir, with the web inf and all in it
[20:13] <olegp> then copy all the static resources, packages and js files into it
[20:13] <olegp> and then zip it up
[20:14] <olegp> btw, agree about the story robi42 - the benefits of ringo should be made more clear somehow
[20:14] <olegp> could even take it a step further and embrace node
[20:15] <robi42> yep, actually making direct comparisons to node
[20:15] <olegp> for example, the way node does threading is by spawing a separate process and passing inputs as serialized json
[20:15] <robi42> and showing where ringo's superior
[20:15] <olegp> so you could actually have a scenario where you use both ?
[20:16] <olegp> node for the io, and ringo for wrapping around java libs
[20:16] <robi42> oh, sounds interesting (never thought about that) :)
[20:16] <olegp> and use webworkers to talk between the two
[20:16] <olegp> given that node is essentially one thread per process, node to node comms is via web workers as well
[20:17] <olegp> so would be neat to slip ringo into the mix :)
[20:17] <robi42> doing everything node doesn't :)
[20:17] <hannesw> interesting idea, but not sure it makes sense
[20:18] <hannesw> jetty is very good about io as well
[20:18] <olegp> yeah, it would be a bit silly, I agree
[20:18] <hannesw> but it sure would be interesting
[20:18] <hannesw> just tried to deploy a google app engine app on tomcat, doesnt work :)
[20:19] <olegp> but it would create a nice migration path for people who have started with node and then realize that theyd still like to use javascript, but dont want to reinvent the wheel and hence would prefer to wrap around an existing java lib
[20:19] <olegp> not sure how many devs like that there are though ... ;)
[20:21] <robi42> interesting stuff. gotta leave now, tho. bye guys :)
[20:21] <olegp> bye!
[20:21] <hannesw> cu robi42
[20:23] <olegp> hannesw, Ill have a go at manually creating a war from a ringo app and document the steps
[20:23] <hannesw> ok, that' a good start
[20:42] <hannesw> ah, app created with ringo-admin create -a is working on tomcat
[20:42] <earl> hm, what about the 0.5 release?
[20:42] <hannesw> only you mast not use symlinks for modules etc
[20:42] <hannesw> earl: what about it?
[20:43] <earl> let's put it out on wednesday, i guess?
[20:43] <hannesw> yes, i'd say so
[20:43] <earl> do we want to get anything specific done until then?
[20:43] <earl> or just bundle up the current git master as is?
[20:43] <hannesw> i personally have a few things i want to get done for 0.5
[20:44] <hannesw> not sure if i succeed
[20:44] <hannesw> documentation for binary would be cool also
[20:44] <earl> mhm, i see jsgi 0.3 and fileupload tagged
[20:44] <earl> yeah, i'll have a go at finishing binary & io docs
[20:44] <hannesw> yes, plus text streams using ringo/encoding
[20:44] <hannesw> and in-memory streams
[20:44] <hannesw> which i need for ringo/subprocess
[20:44] <earl> ah, one thing i wanted to ask about ringo/promise
[20:45] <earl> viz http://gist.github.com/379761
[20:46] <earl> would probably be nicer if defer() returned the actual promise which has a resolve() method
[20:46] <earl> var response = defer(); ... response.resolve(); ... return response;
[20:47] <hannesw> yes, possibly
[20:47] <earl> any specific reason you did it the way it is atm?
[20:47] <hannesw> i basically followed existing code/specs there
[20:47] <earl> ah, ok
[20:48] <earl> so it's supposed to be compatible with other js promise impls?
[20:48] <hannesw> e.g http://wiki.commonjs.org/wiki/Promises/B
[20:48] <hannesw> look for defer()
[20:48] <hannesw> well, it's compatible partially with promises/a
[20:48] <hannesw> or fully, not sure
[20:48] <hannesw> and obviously promises/b is much larger that what we have
[20:50] <earl> ah, yes, fully compatible with promises/a as that only require then(...)
[20:50] <earl> eh
[20:50] <earl> actually not at all compatible with promises/a, as that requires a ternary then() :)
[20:50] <earl> i.e. including a progress handler
[20:51] <hannesw> it doesn't require it
[20:51] <hannesw> and besides, progress handler doesn't work for jsgi
[20:51] <earl> yes, i know
[20:52] <earl> and yes, the progress handler is purely optional it seems
[20:52] <earl> ok
[20:52] <earl> but we'd still be compatible with promises/a if we move the resolve into the promise object itself
[20:53] <hannesw> what's the benefit of having resolve on promise?
[20:53] <hannesw> i kind of like it being hidden away
[20:54] <earl> mhm, i'm just reading thru the commonjs promises stuff to get the reasoning behind this
[20:54] <earl> the benefit imo would be a cleaner api
[20:59] <earl> user-level, that is
[20:59] <earl> ok, lots of security-related stuff that seems to concern commonjs promises
[21:00] <earl> well, an alternative would simply be to directly handle the "Deferred" objects (as created by defer()) in our jsgi/webapp impls
[21:02] <hannesw> don't know, i actually like the current scheme
[21:03] <earl> that's because you wrote it
[21:03] <earl> :)
[21:03] <hannesw> no, i wrote it that way because i like it
[21:03] <earl> what do you like about `return response.promise;` ?
[21:04] <earl> i'm already explicitly creating a promise with `defer()`, why can i not simply return that?
[21:05] <hannesw> because i want to keep resolve away from the promise user
[21:05] <earl> what if i don't care?
[21:05] <hannesw> no big problem
[21:05] <earl> i estimate that 99.95% of jsgi/webapp users don't care about that
[21:06] <earl> and those who care, can always write the more verbose `return response.promise`
[21:14] <earl> mind me, i'm only talking about the jsgi example as shown in http://gist.github.com/379761
[21:15] <earl> where the promise "user" is the jsgi stack (or any middleware)
[21:15] <earl> i don't see what the increased verbosity buys us in this case
[21:17] <hannesw> i don't think it's so bad. you can try to mobilize other ringo users to convince me :)
[21:18] <earl> argh :)
[21:18] <earl> you are totally mindfucked by the verbosity of java, it seems :)
[21:19] <earl> a totally useless `.promise` in each and every async jsgi app is objectively bad :)
[21:20] <earl> but compared to the monstrisities regularly found in other languages and apis, this is a minor point, i guess
[21:24] <hannesw> i like the word "promise".
[21:25] <hannesw> gotta go now
[21:25] <hannesw> good night!
[21:25] <earl> sleep well
[22:04] <ringostarr> 2d7a04b Andreas Bolka: Fix whitespace
[22:04] <ringostarr> 6930d05 Andreas Bolka: Launch java with exec in Debian /usr/bin/ringo
[22:24] <ringostarr> 9b4a841 Andreas Bolka: Fix whitespace
[23:29] <ringostarr> 861817b Andreas Bolka: Fix whitespace and linewidth
[23:29] <ringostarr> 60c29f0 Andreas Bolka: Fix whitespace, linewidth & typos
[23:29] <ringostarr> f679d48 Andreas Bolka: Add documentation stubs for binary.ByteString
[23:51] <ringostarr> 866efb5 Andreas Bolka: Add docs for ByteString as per CommonJS Binary/B