Hopbot log for 2007-08-21 - Helma IRC channel: #helma on irc.freenode.net

2007-08-21:

[8:25] <zumbrunn> http://my.opera.com/kilsmo/blog/2007/08/20/helma-finally-something-for-me
[13:05] <msimoni> howdy y'all
[13:05] <msimoni> i have a question re background threads in helma
[13:06] <msimoni> is using a java runnable the way to go?
[13:13] <zumbrunn> msimoni, Helma also offers built-in support for background threads...
[13:13] <zumbrunn> http://helma.zumbrunn.net/reference/app.html#addCronJob
[13:13] <zumbrunn> http://helma.zumbrunn.net/reference/app.html#invokeAsync
[13:14] <msimoni> thanks
[13:14] <msimoni> i need to listen to broadcast UDP packets in the background
[13:15] <msimoni> i guess invokeAsync with a function that runs forever would work
[13:40] <msimoni> is app.data thread-safe -- can I just put data into it from a background thread?
[13:42] <zumbrunn> Probably. I've never done it, so I'm not sure
[13:43] <msimoni> is it a objectmodel.db.Node?
[13:43] <zumbrunn> I would have to look at the source
[13:45] <zumbrunn> (I wouldn't think that's what it is)
[13:45] <msimoni> no, it's a TransientNode
[13:47] <msimoni> so, is there some way to do synchronization between threads?
[13:48] <zumbrunn> nothing special that I'm aware of
[13:48] <msimoni> hm... i'll just put a Java Hashtable (which is sycnhronized) into app.data.foo
[16:58] <js1> nick /jsp_
[16:59] <jsp_> any tips on setting up my own Helma build environment?
[17:05] <jsp_> 'cause to make e4x really practical for [X]HTML page generation, you consistently need to do a few things to the output, and seeing as JavaScript string handling is not so fast, I'm thinking it would be better to do in Java
[17:09] <zumbrunn> nothing special beyond the need to have cvs and ant installed
[17:10] <zumbrunn> plus I would suggest you comment out the jsdoc antcall in the package target in build.xml
[17:10] <jsp_> those'll keep me busy for a while, I think. no experience with either, and on windows. (I use SVN constantly, but no CVS)
[17:11] <zumbrunn> anyway, to do what you want, I don't think you need to build Helma yourself
[17:12] <jsp_> just call the java methods from javascript?
[17:12] <zumbrunn> you can write your Java code, create a jar and drop it in the ./lib/ext/ directory
[17:12] <zumbrunn> yes
[17:13] <jsp_> well, I have no build environment for Java, either. last time I did it was an independent study in college
[17:13] <zumbrunn> at the very least you'll need a way to compile your java files to .class files
[17:14] <jsp_> (and truth be told I never figured out the path stuff or whatever to get my code to run outside of my IDE back then)
[17:15] <zumbrunn> Helma will take care of the classpath stuff
[17:15] <zumbrunn> you just need to put your files into the ./lib/ext/ dir
[17:16] <jsp_> I found out response seems to have some more methods than are documented.
[17:16] <zumbrunn> which ones?
[17:17] <jsp_> encode/encodeXML/encodeForm/format
[17:18] <jsp_> nevermind--I just missed them
[17:18] <jsp_> in the docs
[17:18] <jsp_> except encodeForm, which isn't there
[17:28] <zumbrunn> thanks, fixed (in cvs)
[17:30] <msimoni> apropos, you might want to add to the documentation of app.invokeAsync that timeout=-1 causes the task to run forever.
[17:33] <zumbrunn> msimoni, will do
[17:35] <zumbrunn> msimoni, do you by any chance know what the default is?
[17:35] <zumbrunn> (if no timeout is specified)
[17:36] <msimoni> in RequestEvaluator it says 15 minutes:
[17:36] <msimoni> // give internal call more time (15 minutes) to complete
[17:36] <msimoni> return invokeInternal(object, function, args, 60000L * 15);
[17:37] <zumbrunn> ok
[17:37] <msimoni> personally, I think that the invokeAsync should use -1 as default
[20:58] <ismith> so, anyone know how you might go about preventing SQL injection in Helma?
[21:14] <jsp_> safest: use only the built-in ORM
[21:15] <jsp_> best: write a much better helma.Database substitute to make it possible to use the parameterized queries that JDBC supports
[21:15] <jsp_> workable: write an escaping method for strings and be careful
[21:17] <jsp_> JavaScript has been mostly unicode-aware for, IIRC, the second point version way back in the day, so the charset manipulation attacks that break basic string escaping in, e.g., PHP should not be possible here, so a very simple escaping method should work
[22:30] <ismith> thanks jsp

 

 

In the channel now:

Logs by date: