Logs for the RingoJS IRC channel, as logged by ringostarr.

2010-12-10

[01:16] <mrdon_> morning

[09:49] <mrdon__> morning

[09:49] <hannesw> good morning mrdon__

[09:50] <mrdon__> surely it is morning somewhere anyway

[09:50] <hannesw> it is now, here :)

[09:50] <mrdon__> ah, evening here (sydney)

[09:50] <mrdon__> thanks for the reply on the sandbox thing

[09:50] <mrdon__> just finished a response. tl;dr version is mine is in-process so security manager won't work

[09:51] <hannesw> so you're using a special java wrapper, right?

[09:51] <mrdon__> wrapfactory?

[09:52] <mrdon__> yes

[09:52] <hannesw> the shared/not shared module thing would probably be easy to implement in ringo

[09:52] <mrdon__> still in the prototype phases, so I likely have missed things

[09:52] <hannesw> we do have this feature, just it's controlled from within the module (by setting a boolean __shared__ flag)

[09:52] <mrdon__> yeah, shouldn't be too hard to override then

[09:53] <hannesw> I'd be interested in adding the module loading hooks you need

[09:53] <hannesw> if you're willing to guide me :)

[09:55] <mrdon__> sure, are you familiar with the rhino impl?

[09:55] <mrdon__> they have an object called Require

[09:55] <mrdon__> I had to fork that to allow executeModuleScript to be overridden

[09:55] <hannesw> right

[09:56] <mrdon__> then use that to switch the sandbox on or off

[09:56] <hannesw> what exactly is involved in that? setting wrapfactory, something else?

[09:56] <mrdon__> for the state bit, I added an interface CacheDecider that Require will call to determine if the module should be added to its cache

[09:56] <hannesw> ok

[09:57] <mrdon__> lemme see if I can get you access to the source, hold on

[09:58] <mrdon__> https://labs.atlassian.com/source/browse/CJS/trunk/ssjs-plugin/src/main/java/com/atlassian/labs/ssjs/DefaultScriptManager.java?r=HEAD

[09:58] <mrdon__> a bit messy, but there it is

[09:58] <hannesw> thanks!

[09:58] <mrdon__> also, I was wrong, I don't use that override anymore, I think I just preload all the core modules with a context that isn't sandboxed

[09:59] <mrdon__> or at least that was the strategy I was going for when I thought to maybe use ringo

[10:00] <mrdon__> unfortunately, the classshutter doesn't do the sandboxing I want, as if a core module needs the class, it is in forever

[10:00] <mrdon__> the wrap factory does the trick

[10:01] <hannesw> yes, that's a problem with classshutter

[10:02] <hannesw> will also apply with custom java wrappers - if a trusted module passes a wrapped object to untrusted code

[10:03] <mrdon__> true

[10:03] <hannesw> that's the nice thing about the java code origin approach

[10:04] <mrdon__> well, my goal isn't to be completely secure, just be more secure than java plugins

[10:04] <mrdon__> yeah, just not very embed friendly

[10:04] <hannesw> true.

[10:04] <mrdon__> I also added the neat trick to prevent infinite loops by adding an execution listener

[10:04] <mrdon__> amazing stuff you can do in rhino when the scripts aren't compiled

[10:05] <hannesw> I think that's even possible in compiled mode by now (not sure though)

[10:05] <mrdon__> I saw all the recent commits coming from a helma person, would that be you?

[10:05] <hannesw> yes

[10:06] <mrdon__> nice...rhino was pretty much abandoned a few years back

[10:06] <mrdon__> good to see it getting some love

[10:06] <hannesw> well, it could use even more :)

[10:06] <mrdon__> need to find a way to borrow those v8 devs ...

[10:07] <hannesw> right :)

[10:07] <hannesw> but it's a solid piece of software

[10:07] <mrdon__> yep, and oddly advanced due to its impl of 1.7

[10:08] <hannesw> js 1.8 even (mostly)

[10:08] <mrdon__> nice

[10:09] <mrdon__> also, any thought about sandboxed core modules?

[10:09] <hannesw> that's what the destructuring assignment is: var {property} = object

[10:09] <mrdon__> would I simply fork then delete what I don't want?

[10:09] <mrdon__> ah

[10:11] <hannesw> you could do that, or you could start from scratch with external safe core module

[10:11] <hannesw> you can create sandboxed engines with custom module paths

[10:11] <mrdon__> well, a lot of the value would be reusing the jsgi, promises, scheduler, etc stuff

[10:12] <mrdon__> but yes, looks like a different module path will be the way to go

[10:12] <hannesw> you could probably just pick and choose, copying whatever you need to your secure modules folder

[10:12] <mrdon__> and passing in that map blocks off the methods from RingoGlobal I don't want?

[10:23] <hannesw> no, these are additional

[10:24] <mrdon__> ah, any good way of blocking those methods?

[10:25] <mrdon__> I'd block all but maybe print, seal, and sync

[10:28] <hannesw> hm, that map was intended to pass in globals, but i guess could be used to limit global as well

[10:28] <hannesw> maybe that would be more useful

[14:30] <mrdon__> how stable is stick?

[14:39] <earl> mrdon__: work in progress

[14:55] <mrdon__> gotcha :)

[14:55] <mrdon__> well, looks pretty good so far

[14:56] <mrdon__> was looking for something sinatra-like

[14:56] <mrdon__> I enjoyed using express

[14:56] <mrdon__> if only it worked with jsgi :/

[14:56] <mrdon__> even then, I notice many of the "lightweight" frameworks use nodejs-specific modules

[14:57] <oberhamsi> if your app isn't too involved you probably get away with using ringo/webapp (pretty stable) and porting later

[15:02] <mrdon__> well, I like a number of the features, specifically the rendering abstraction and straightforward routing

[15:02] <mrdon__> so perhaps keeping up with changes will be the cost

[15:02] <mrdon__> anyway, this isn't anything that is going into production tomorrow; just playing with the possibilities

[15:48] <hannesw> oravecz: are you ok with this? https://github.com/ringo/ringojs/pull/114

[16:30] <oravecz> yes, that change will allow someone to package or install without having to run tests.

[16:31] <oravecz> Do I need tp rewrite the auto-discovery of packages in JS instead of in RingoConfiguration.java?

[16:35] <earl> oravecz: please try, yes

[19:24] * oberhamsi likes new stick skeleton app

[21:34] <hannesw_> oberhamsi: good thing earl talked me out of this i guess: https://github.com/hns/stick/blob/336e7e4cc88808658ece41607daca6f2568c1d94/skeleton/app/main.js

[21:35] <oberhamsi> yeah i never had it like that, luckily :) and before you talked about it, i hadn't noticed the skeleton app :|

[21:35] <hannesw_> but actually the github version was old already...

[21:36] <hannesw_> pushed new commit that adds stick/server module/script

[21:36] <hannesw_> so skeleton/app/main.js is further slimmed down...

[21:37] <hannesw_> https://github.com/hns/stick/blob/master/skeleton/app/main.js

[21:37] <hannesw_> hm, and locally i have made the change so I can configure middleware right in the Application constructor

[21:37] <hannesw_> Application("static", "route", ...)

[21:37] <hannesw_> what do you think about that?

[21:38] <hannesw_> the problem is that Application used to also take a nested app as argument, which conflicts with the middlewares...

[21:40] <oberhamsi> sorry was away... your presence reminded me to send you that pull request :)

[21:40] <hannesw_> oh, ok, thanks

[21:40] <oberhamsi> ah yes even better skeleton

[21:41] <hannesw_> so the main script is now outside the app, which i like less, but it's a good compromise

[21:41] <hannesw_> not as complex as the old webapp code

[21:41] <oberhamsi> didn't grok until today why you export app everywhere :) mount expects to find app

[21:42] <hannesw_> yes, that and the new stick/server script

[21:42] <oberhamsi> main scrip is outside the app? how do you mean *reading stick/server commit stuff*

[21:43] <hannesw_> well originally the whole startup code was inside the skeleton/stick application -

[21:43] <hannesw_> that's the first version of the skeleton/main.js script

[21:44] <hannesw_> and you could use it from the command line and from daemon start script

[21:44] <hannesw_> now that script is part of stick (in lib/stick/server.js)

[21:44] <hannesw_> and it takes the app module as parameter

[21:52] <oberhamsi> ooh now i see

[21:53] <oberhamsi> so some would say you turned a library into a framework with one commit :)

[21:56] <hannesw_> really? that's the tipping point?

[21:57] <hannesw_> well we can still back out if we want :)

[21:57] <oberhamsi> oh well i read at least one guy arguing that way .. about inversionofcontrol being what makes the difference

[22:03] <hannesw_> well I'd still prefer to have all control in the app :)

[22:19] <oberhamsi> sure just saying something smart i noticed :)