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

2010-06-15:

[6:46] <hannesw> oberhamsi currently there is no wait() method in the httpclient's exchange object, right?
[6:46] <hannesw> would be very useful to trigger several requests asynchronously, then wait for all of them to complete
[6:47] <hannesw> (what oravecz asked for yesterday)
[6:47] <hannesw> without using promises
[6:47] <oberhamsi> ah.. no. what would wait() do? why not just shoot all requests?
[6:49] <oberhamsi> "launch several async server-side rest calls and proceed only once all responses return"
[6:53] <oberhamsi> arg thx for fixing convinience invocation, too much cleanup i did
[7:02] <hannesw> wait would wait for the request to finish
[7:02] <hannesw> like doing a sync call, but you can only trigger one sync call at a time
[7:04] <oberhamsi> sounds useful .. be back, got meet
[7:04] <hannesw> yo
[7:20] <ringostarr> 9af2571 Hannes Walln?fer: Add basic JSDoc for httpclient Exchange object
[7:21] <hannesw> so Exchange object in httpclient is documented now:
[7:21] <hannesw> http://ringojs.org/api/master/ringo/httpclient
[7:22] <hannesw> I'd like to add a promise-like api to that object
[7:22] <hannesw> then() and wait() and maybe isDone()
[7:22] <hannesw> http://ringojs.org/api/master/ringo/promise#deferred_promise
[8:20] <ringostarr> e0c2d7b Hannes Walln?fer: Be more careful in jsgi header handling and accept array values as defined by JSGI 0.3
[8:20] <ringostarr> b3d2b3a Hannes Walln?fer: Provide default content type in upload demo
[9:12] <hannesw> hm, probably no point to implement promise api since callbacks will work well in 99% of cases
[9:12] <hannesw> and it's easy enough to use promises directly in the remaining cases
[9:12] <hannesw> but I'm adding wait() and isDone()
[9:18] <oberhamsi> ok cool
[9:42] <ringostarr> 7a4f4f1 Hannes Walln?fer: Add isDone() and wait() methods to httpclient exchange object.
[9:52] <ringostarr> d935f27 Hannes Walln?fer: Improve jsdoc for Exchange.wait() in httpclient
[10:27] <hannesw> oravecz i added isDone() and wait() methods to the httpclient exchange object so you can do multiple async requests and then wait for all of them to complete:
[10:27] <hannesw> http://gist.github.com/438960
[10:27] <hannesw> api docs are here: http://ringojs.org/api/master/ringo/httpclient
[10:28] <hannesw> oberhamsi to me it would feel more natural/intuitive if httpclient exchange object was named "Response"
[10:28] <hannesw> should we rename isDone() to a simple "done" boolean property?
[10:29] <oberhamsi> i kept with exchange b/c it also holds all the request attributes
[10:30] <oberhamsi> .. hm but i don't expose any of the request attributes, so Response would make sense
[10:31] <oberhamsi> so +1 Exchange -> Response
[10:31] <oberhamsi> and +1 isDone() -> done
[10:31] <ringostarr> d1a6b4a Hannes Walln?fer: Refactor isDone() to a boolean "done" property in httpclient Exchange object
[10:33] <hannesw> just went ahead and changed it to "done"
[10:34] <hannesw> "Exchange" is never used in client code anyway, it's merely a name for the returned object, so it should be easy to change
[10:34] <oberhamsi> yep, no one will notice
[12:06] <hannesw> starting to plan for Release 0.6
[12:06] <hannesw> http://ringojs.org/wiki/Release_0.6/
[13:30] <oravecz> hannesw, thanks for providing a means to wait() for httpclient responses
[13:31] <oravecz> fwiw we create our own client and use the exchange object to specify additional properties
[13:31] <oravecz> I don't have a problem with the name tho
[13:31] <oberhamsi> oravecz, what's the advantage of your own client?
[13:31] <oravecz> I don't remember if I was using that to expose the async property. Is being able to specify async on the convenience methods a new capability?
[13:32] <oberhamsi> oh you mean you create a client instance... okay, i get it
[13:32] <oberhamsi> with convinience you can too specify async, but full blown client is probably better for what you do.. lots of reqs, etc
[13:37] <oravecz> ok, thx
[14:28] <hannesw> oberhamsi i don't think you can do async requests with httpclient convenience funcs, can you?
[14:29] <oberhamsi> hannesw, right! you can not. async was old default behaviour... /confused
[18:55] <oravecz> will using the Java classpath as a source for module loading cause problems when a change to a file should cause reloading?
[19:33] <earl> oravecz: it should not
[19:33] <earl> and i'd suggest in any case, looking at using ringo.jar in the module path and storing your app's (js) sources somewhere in WEB-INF (as you are doing already, iirc)
[19:33] <earl> that sounds like a clean approach to me
[19:34] <oravecz> I'm doing that now, but I will switch when Hannes gets the classloading approach implmented
[19:34] <earl> so you dropped the custom ringo dissection stuff already?
[19:34] <oravecz> ?
[19:35] <oravecz> oh, in our maven builds?
[19:35] <earl> iirc, yesterday you had the whole of ringo copied to web-inf
[19:35] <earl> i'd use the ringo.jar along with the ringo stdlib stored in the jar
[19:35] <earl> and have only the app in WEB-INF/
[19:36] <earl> (and i would have to think about ringo packages, though :)
[19:36] <oravecz> well, i have to see how classloading works before making that descision
[19:37] <oravecz> in my ideal world, i would only drop ringo.jjar and mypackage.jar in the WEB-INF/lib directory and be done with it
[19:37] <earl> maybe ;)
[19:37] <oravecz> it's been a while since I dabbled in classloader world, but at one time, once a class was loaded, it was cached by Java and couldn't be refreshed.
[19:37] <earl> why would that be an issue?
[19:38] <earl> would you need core ringo classes to be refreshed?
[19:38] <oravecz> not that often i suppose, just when we are tweaking things
[19:38] <oravecz> there are some commercial products (java rebel iirc) which overcame this problem, but it isn;t as seamless as loading modules from the file system
[19:39] <earl> are we talking about js modules or java classes here?
[19:39] <earl> js module refreshing will still work
[19:40] <oravecz> the refresh problem would be for my classes which would reside in <root>/src/main/resources
[19:40] <oravecz> so, they would get copied to WEB-INF/classes and be subject to classloading restrictions (if they still have a problem with reloading)
[19:41] <earl> what's that got to do with where ringo's classes are stored :) ?
[19:41] <oravecz> separate issue, i can live with ringo and packages not reloading
[19:42] <oravecz> if my app files have to live under WEB-INF/app, then so be it
[19:42] <oravecz> But the "more natural" maven location for these files is probably in the resources folder since those files are made available on the classpath
[19:42] <earl> i'm not talking about a classpath solution
[19:43] <earl> i'm talking about a cleaner deployment with what we already have
[19:43] <oravecz> i know, you are talking about a hybrid
[19:43] <earl> now, purely with current ringojs
[19:43] <earl> no*
[19:44] <earl> ringo core in ringo.jar, add ringo.jar to the module path, have your app in web-inf
[19:44] <oravecz> i should try loading the resources from ringo.jar and see. How do I configure it?
[19:44] <earl> i think adding ringo.jar to the module path should do it
[19:44] <earl> but that's what i'd be interested in finding out :)
[19:45] <oravecz> <init-param>
[19:45] <oravecz> <param-name>module-path</param-name>
[19:45] <oravecz> <param-value>app,packages,lib</param-value>
[19:45] <oravecz> </init-param>
[19:45] <oravecz> that's my current init-param
[19:45] <oravecz> 'modules' is hard coded in RIngoConfiguration
[19:45] <oravecz> so that is a fourth search path
[19:46] <oravecz> and these are all relative to ringo-home
[19:46] <earl> lib/ is ringo library?
[19:46] <oravecz> scratch 'lib'. it is leftover from an experiment
[19:46] <earl> ah, ringo-home
[19:47] <earl> well
[19:47] <earl> i'd try setting ringo-home to point to the .jar
[19:47] <oravecz> yeah, so I am not sure how to resolve stdlib in ringo.jar while supporting other root paths as well
[19:48] <earl> and then add proper paths to app/ and packages/ in the module-path
[19:48] <oravecz> then i would fail to resolve app and packages
[19:48] <oravecz> oh, absolute paths
[19:48] <earl> well, that's the main question
[19:48] <oravecz> yeah, that gets smelly quick :)
[19:49] <earl> paths relative to the working directory is what i'd want
[19:49] <oravecz> especially since ringo.jar will be in the maven repository and not WEB-INF/lib (well at least until a WAR file is created)
[19:49] <earl> basically, i'd suggest the following:
[19:49] <oravecz> I would just want to be able to specify paths relative to the Java classpath with reloading capability
[19:49] <earl> ringo-home: ringo.jar
[19:49] <earl> module-path: WEB-INF/app,WEB-INF/packages
[19:50] <oravecz> module-path is resolved relative to ringo-home
[19:56] <earl> yes, should be absolute paths to app and packages
[19:57] <earl> /WEB-INF/app
[19:58] <earl> if you have a maven dependency on ringo, would ringo.jar automatically be copied to web-inf/lib upon creating a war?
[19:58] <oravecz> yes
[19:58] <earl> do you ever run the webapp w/o a war?
[19:58] <oravecz> yes
[19:58] <earl> how?
[19:58] <oravecz> during dev you often just do mvn jetty:run which runs the files in place
[19:59] <earl> w/o preparing web-inf properly?
[19:59] <oravecz> this allows you to make a change to a file and immediately see the response
[19:59] <oravecz> yes
[19:59] <earl> ok
[19:59] <earl> am i correct, that in this case, ringo.jar would only be on the classpath, but not in web-inf/lib?
[19:59] <oravecz> the key is to not lose the quick roundtrips
[20:00] <oravecz> yes, kinda. Because of maven, the jetty plugin knows to treat all of the dependencies as belinging to WEB-INF/lib without actually having them there
[20:00] <oravecz> A file like ringo.jar (or mongodb.jar) would actually live in your maven repository (~/.m2/repository)
[20:00] <earl> ok
[20:01] <earl> good, thanks, i'll think about this a bit more
[20:01] <oravecz> ok :)
[20:03] <earl> will have to look at what else we use ringo-home for