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

2007-09-12:

[0:01] <Lonnie> So, you'd have to put all your business logic in C instead of java.
[0:01] <peter_12> everything you write is in JavaScript for both, I believe
[0:01] <peter_12> I'm just new too
[0:01] <peter_12> but Mozilla releases two implementations of JavaScript
[0:01] <peter_12> Rhino is the JavaScript engine written in Java
[0:02] <Lonnie> Well, there are certain things (in both) that are better placed in pre-compiled code.
[0:02] <peter_12> Spidermonkey is the JavaScript engine written in C
[0:02] <peter_12> ok
[0:03] <Lonnie> Right, I understand that they interpret javascript the same.
[0:03] <peter_12> it's all faster to run if everything is written in assembly :)
[0:04] <Lonnie> Indeed, but I would guess that there is a 10 fold speed increase using precompiled code versus interpreted javascript.
[0:05] <peter_12> I suppose it is a "what's fast enough?"
[0:05] <peter_12> and then the discussion changes to what's faster to programm
[0:06] <Lonnie> When I first started doing dynamic web pages, I used ASP which was a interpreted scripting language.
[0:08] <Lonnie> Then I moved to ASP.net, where most of my code was in c#. The first web request, required compiling, but thereafter it was precompiled. This made things really fast.
[0:09] <Lonnie> For example, http://www.lonniebest.com/FormatCSS/
[0:10] <Lonnie> The first time you submit some CSS, the application compiles the c# code I wrote. However, there after, subsequent submissions of CSS are process using precompiled code. It does this very very fast. Way faster than it would if the code was interpreted javascript.
[0:12] <Lonnie> So, in Helma, I would put this type of code in java, and use javascript only for facilitating this java communication.
[0:14] <Lonnie> If I used whitebeam. I suppose my code would be in C, and I'd likewise use javascript to facilitate the communication with my c component/service.
[0:32] <Lonnie> Can a Helma application scale to utilize multiple servers like this:
[0:32] <Lonnie> http://www.whitebeam.org/images/archover.gif
[2:32] <Lonnie> I understand that you can use Helma with or without apache. So which do I want to choose. What are the considerations.
[3:44] <Lonnie> I'd appreciate any thoughts you all have about Phobos.
[7:13] <zumbrunn> Lonnie, both phobos and whitebeam seem to be more page centric than helma
[7:14] <zumbrunn> in other words, you tend to write templates that handle page requests and insert the javascript into these templates
[7:15] <zumbrunn> and whitebeam does this in a XML centric way
[7:18] <zumbrunn> regarding multiple servers, there are HelmaSwarm and HelmaGroup that would help scaling in two different ways
[7:18] <zumbrunn> http://adele.helma.org/download/helma/contrib/helmaswarm/
[7:18] <zumbrunn> http://helma.org/stories/77390/
[7:31] <zumbrunn> peter_12, in case you'll check the hopbot log file looking for an answer... you can run helma without jetty, inside any other servlet container
[7:31] <zumbrunn> but I believe this hasn't been done for years now
[7:32] <zumbrunn> so there might be needs to tweak Helma in places where the current code evolved to be jetty specific
[7:33] <zumbrunn> what's the alternative Java http server you were thinking about earlier?
[7:35] <zumbrunn> (or maybe you just meant alternative servlet containers)
[14:35] <zumbrunn> hi peter_12, what is it that you don't like about using jetty?
[14:36] <peter_12> hi zumbrunn: nothing :)
[14:36] <peter_12> I'm just figuring out the whole helma architecture
[14:37] <zumbrunn> ok, see http://helma.zumbrunn.net/hopbot/ for what I said about it a few hours ago
[14:37] <peter_12> it seems that launcher.jar contains "main" and that helma is a Java application with both a jetty server and the Rhino engine embedded
[14:38] <zumbrunn> yes, but it would be possible to use it in for example tomcat with some tweaking
[14:39] <zumbrunn> but since there is no real reason/benefit to do this, I don't think anybody has done it in recent years
[14:39] <peter_12> if used with Tomcat then the server would not be embedded, correct? Instead Tomcat would be a running app and would call a helma running app, correct?
[14:40] <peter_12> (thanks I read the hopbot log)
[14:40] <zumbrunn> yes, helma would be a servlet in tomcat
[14:40] <peter_12> ok
[14:41] <peter_12> have you found any limitations with the Jetty server being embedded in the helma app as opposed to the more "normal" apache httpd architecture where server runs and calls other programs?
[14:42] <zumbrunn> usually apache httpd *is* used for production deployment of helma
[14:42] <zumbrunn> jetty just runs behind apache in that case, for example using mod_proxy
[14:43] <zumbrunn> or more traditionally, mod_jk
[14:43] <zumbrunn> personally, I like the simplicity of directly deploying using jetty
[14:44] <peter_12> What I mean is in mod_perl or Rails application the server is not embedded in the web app. It is almost the other way around
[14:44] <zumbrunn> that's really the case with helma as well, I think
[14:44] <zumbrunn> it's just additional layering
[14:45] <zumbrunn> launcher is a java app that embeds jetty, which embeds helma
[14:45] <zumbrunn> (I think)
[14:46] <zumbrunn> there are two main problems with directly deploying using jetty
[14:46] <zumbrunn> it would have to run as root to be listening on port 80
[14:46] <zumbrunn> and the current setup can't handle https
[14:47] <zumbrunn> both would probably be possible to work around, but nobody has done that, since deploying jetty behind apache is the easier solution
[14:48] <peter_12> ahh ok
[14:49] <peter_12> reading the helma tutorials in more detail this time, I see that helma is very close to what I wrote down as my ideal web development framework
[14:50] <peter_12> the idea of a url as a method call on an object
[14:50] <peter_12> that is what I want
[14:50] <zumbrunn> yes, and that is the main difference compare to phobos and whitebeam, I believe
[14:51] <peter_12> the other feature I wanted was all files for one of these particular objects to be in the same directory
[14:51] <peter_12> In rails they are spread out over four places
[14:52] <zumbrunn> in helma is can spread them out if you want
[14:52] <zumbrunn> but they don't have to be
[14:52] <peter_12> why Rhino and not Spidermonkey for Helma?
[14:53] <zumbrunn> because it's Java
[14:53] <zumbrunn> Java is both an advantage and a disadvantage
[14:53] <zumbrunn> it's currently still harder to deploy, because you need a JRE
[14:54] <zumbrunn> but you get the benefit of directly being able to use all the Java libraries
[14:54] <peter_12> right
[14:54] <leobm> with java you has access to a huge choice of libraries for all known problems.
[14:54] <leobm> and simpler than with c
[14:54] <peter_12> is it really *that* hard to deploy?
[14:55] <leobm> and rhino is not so slow how you think
[14:55] <zumbrunn> only if you have an ISP that doesn't want to support Java
[14:55] <leobm> http://blog.formatvorlage.de/2007/07/13/javascript-performance-rhino-vs-spidermonkey-2/
[14:55] <peter_12> I imagine the slow bit is a stereotype
[14:56] <leobm> and which ISP support C?
[14:56] <peter_12> I looked into building a web framework with Spidermonkey and it really looked like a huge uphill battle
[14:56] <leobm> I think it's harder to support spidermonkey than rhino on java
[14:56] <leobm> peter_12: do you know wxjs ?
[14:56] <peter_12> yes
[14:56] <leobm> in wxjs is a apache mod for javascript
[14:58] <leobm> i like the rhino implementatzion of sun. I think sun add some features I want see in org. rhino
[14:58] <peter_12> leobm it looks like rhino is faster on that page you linked
[14:58] <leobm> better getter and setter support than this dirty thing in org. rhino
[14:58] <peter_12> Sun has it's own JavaScript implementation?
[14:58] <leobm> in the first test.. spidermonkey is better..
[14:59] <leobm> I think you must first look on the problem.. and than test the engine.
[14:59] <leobm> you know that you can compile Rhino javscript code to java bytecode ?
[14:59] <peter_12> makes sense
[14:59] <leobm> than .. javscript run in JIT..
[15:00] <zumbrunn> being able to deploy using a simple apache module makes it more interesting/easier for ISP's to support a new platform
[15:00] <zumbrunn> would be nice if we could do that with Helma
[15:00] <zumbrunn> that was the idea behind mod_gcj and Rhinola
[15:00] <peter_12> mod_helma?
[15:00] <leobm> yes.. but waht is with the libraries ?
[15:01] <zumbrunn> I think that still works
[15:01] <zumbrunn> but the question is what will happen with gcj now
[15:01] <zumbrunn> (now that Java is GPL)
[15:02] <leobm> ok, gcj is nice
[15:02] <peter_12> Helma has been around for quite a while now, why do you think it hasn't caught on as the greatest thing ever?
[15:02] <leobm> I know some people they code opengl demos in java and compile it with gcj to native code. works very well
[15:02] <zumbrunn> because the non-Java folks are scared away because it's Java and the Java folks are scared away because it is not Java?
[15:03] <leobm> helma is not perfect. I hate sometime the to simple ORM
[15:04] <leobm> some good ideas has Phobos e.g. too
[15:04] <zumbrunn> like what?
[15:04] <leobm> JPA
[15:04] <leobm> access
[15:05] <peter_12> I watched the Phobos video and it was very good but it didn't seem quite right to me. I can't remember why
[15:05] <leobm> I wrote my own little rhino web framework.
[15:06] <leobm> bsaed on code of trimjunction... restlet.. e.g
[15:07] <leobm> and now I try connect it with hibernate.
[15:07] <leobm> http://jroller.com/garymak/category/Hibernate
[15:08] <zumbrunn> rethinking the current ORM is definitely on the plates for a future Helma version
[15:08] <zumbrunn> and there are several partial proposals floating around
[15:08] <leobm> uppps. wrong link.
[15:08] <leobm> I mean http://jpmoresmau.blogspot.com/2007/05/javascript-and-hibernate-hand-in-hand.html
[15:08] <zumbrunn> but no real agreement yet in which direction to go, I believe
[15:08] <zumbrunn> but maybe there doesn't need to be agreement
[15:09] <leobm> I like the helma think connects Object direcly with url..
[15:09] <peter_12> zumbrunn: what about Rails ActiveRecord style ORM?
[15:09] <zumbrunn> maybe the helma core can get even more flexible than it is already, so that different ORM approaches can be cleanly implemented on top of it
[15:10] <leobm> but sometimes I cant solve very simple sql problems with the helma possibilities directly. most I must write sql once again. I'm not sure that this is the sense of ORM
[15:11] <leobm> peter: activerecord is not the last idea. but often to simple too. for complicated problems it's most not good enough too.
[15:11] <zumbrunn> Hannes seems to favor the idea to use a scheme as the defining place from which automatic mapping would be done
[15:12] <zumbrunn> some want it to be done in code
[15:12] <leobm> "helma think" => "helma way"
[15:13] <zumbrunn> personally, I currently think something like couchdb as a replacement for the embedded xml db would be nice
[15:13] <leobm> yes
[15:13] <zumbrunn> many ways lead to rome
[15:14] <zumbrunn> so, flexibility should maybe be the most important goal
[15:14] <leobm> I like ideas of Og (Nitro framework ruby) ..
[15:14] <leobm> I kile Ideas of the object db db40
[15:15] <leobm> I like some ideas of seaside web framework (continutions) ..or wee frameowork (ruby )
[15:15] <leobm> db4o
[15:16] <leobm> Every programmer should look over the border.

 

 

In the channel now:

Logs by date: