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

2008-08-23:

[13:43] <jkridner|work> anyone ever do load balancing with the native database?
[13:44] <jkridner|work> btw, I was able to get Helma to run on my ARM-processor based board using JamVM and GNU Classpath. :)
[17:47] <peter_12> zumbrunn_: ping
[17:48] <zumbrunn_> pong
[17:48] <zumbrunn_> you pinged me at the right time
[17:48] <zumbrunn_> was away from the keyboard for a few hours until this very moment
[17:49] <peter_12> let's hope the luck continues
[17:49] <peter_12> I'm the guy that's been working xjs
[17:49] <zumbrunn_> yep, I remember
[17:50] <peter_12> I've taken a bit of a break for the last couple months working on some "real" work but now I'm getting back to working on the module system for xjs
[17:50] <peter_12> I'm curious if there is any way that Helma NG and xjs could share the same kind of module system and both be distributed through the same CPAN type repository
[17:51] <peter_12> like an apt or yum repository
[17:51] <zumbrunn_> the plugin/distribution system for helma-ng is on the todo list
[17:51] <zumbrunn_> so, it's certainly the right time to discuss this
[17:52] <peter_12> I actually think Helma could probably be a xjs module
[17:52] <peter_12> actually I want to change from the word "module" to "package"
[17:53] <peter_12> I use Debian with apt and dpkg as my gold standard for a package system
[17:53] <peter_12> I want to have the following system in general
[17:53] <peter_12> before I describe it, would it be better to do this by email on the helma list?
[17:54] <peter_12> is there a wider audience that way?
[17:54] <zumbrunn_> probably would be
[17:54] <zumbrunn_> yes
[17:54] <peter_12> so the Helma NG mailing list?
[17:54] <zumbrunn_> most importantly, it's the preferred way for hannes to discuss these kinds of things
[17:54] <peter_12> ok
[17:55] <zumbrunn_> yes, there is a google group for helma-ng now
[17:55] <peter_12> did you ever give xjs a try?
[17:55] <zumbrunn_> replacing the previous mailing lists
[17:55] <zumbrunn_> only to the point where I installed it in a separate directory, as to your instructions
[17:56] <zumbrunn_> and looked around a bit at what it put there
[17:56] <zumbrunn_> but I never attempted to do enything useful with it yet
[17:56] <peter_12> ahh ok. Just curious if you had the general idea
[17:56] <peter_12> Is Helma NG headed in the direction of a Perl/CPAN-type of system?
[17:57] <zumbrunn_> it's not determined yet
[17:57] <zumbrunn_> which is why it's the right time to discuss it
[17:57] <peter_12> are there other options that have been discussed?
[17:57] <zumbrunn_> hannes might have a concrete idea for how he wants to implement the plug-in system
[17:58] <zumbrunn_> but I don't think he has shared that yet
[17:58] <peter_12> ok, I will write up a proposal to the group
[17:58] <zumbrunn_> ok
[17:59] <peter_12> BTW, what do you think of a Perl/CPAN-type system?
[18:00] <zumbrunn> I wonder if it isn't more complex than it needs to be for what we need for helma-ng
[18:00] <zumbrunn> but I might over estimate the complexity
[18:00] <zumbrunn> or underestimate the benefits
[18:33] <peter_12_> zumbrunn: http://groups.google.com/group/helma-ng/browse_frm/thread/2730a822cb16cf5d
[18:33] <peter_12_> I look forward to reading what you guys think
[18:41] <zumbrunn> namespace protection doesn't apply anyway in the context of helma-ng modules
[18:42] <zumbrunn> since each module gets its own scope
[18:46] <zumbrunn> presumably, that's also an aspect that makes code resuse between helma-ng and xjs more difficult, since you don't do anything like that, right?
[18:47] <zumbrunn> using xjs code in helma will likely be easier than the other way around
[18:51] <peter_12_> "each module gets its own scope"?
[18:52] <zumbrunn> yes, each .js file, really
[18:52] <peter_12_> what do you mean by "scope"?
[18:52] <zumbrunn> it gets a global object that inherits from a shared global object through the prototype chain
[18:53] <peter_12_> no I don't do anything like that.
[18:53] <peter_12_> I just don't see the world as being so complicated.
[18:53] <peter_12_> this may not preclude common infrastructure and some code sharing
[18:54] <zumbrunn> yep, I agree
[18:55] <zumbrunn> just wanted to point out that the namespace issue isn't really an issue in the context of helma-ng
[18:55] <zumbrunn> and that on the downside, this means code sharing will be easier in one direction than the other
[18:55] <peter_12_> Is there a simple module that you could sketch out, perhaps JSON, and how it would work in helma-ng?
[18:56] <zumbrunn> "module" in helma-ng right now is just a .js file
[18:56] <peter_12_> it is a one-to-one correspondence?
[18:56] <zumbrunn> plus there are "repositories" or "module paths"
[18:57] <zumbrunn> where helma knows to look for files/resources
[18:57] <peter_12_> I have a module path also
[18:57] <zumbrunn> and then "plugins" might be something else on top of that
[18:57] <peter_12_> normally it just needs to be /usr/local/lib/xjs
[18:57] <peter_12_> Rails has this concept of plugins and I just don't see the point
[18:58] <peter_12_> Catalyst just uses CPAN packages from the ground up
[18:58] <peter_12_> In this regard I think Catalyst is miles ahead of rails
[18:59] <peter_12_> Rails had components, plugins, lib directory, regular libs on the system, gems. Rails basically dropped the ball in this area in a big way.
[19:00] <peter_12_> As long as Helma as the concept of a "lib" directory containing JavaScript files and a load path then I think there could be common ground for distributing the files that end up in that lib directory.
[19:00] <peter_12_> if code can only really be shared in one direction that is ok
[19:04] <zumbrunn> it would still work both ways
[19:04] <peter_12_> sure. The helma code would just introduce more global variables, correct?
[19:05] <zumbrunn> exactly
[19:05] <zumbrunn> http://dev.helma.org/wiki/Modules+and+Scopes+in+Helma+NG/
[19:05] <peter_12_> the reason I decided to go with a single global object is that is the most natural in JavaScript. It is also the way the browser works. So if I write code that is considerate on the server side, that is introduces only one global object, then that code can be shared with the client.
[19:05] <peter_12_> I'm reading that link now
[19:05] <zumbrunn> it has come up on es-discuss recently as well
[19:05] <zumbrunn> https://mail.mozilla.org/pipermail/es-discuss/2008-August/006915.html
[19:07] <zumbrunn> oops, I meant this one:
[19:07] <zumbrunn> https://mail.mozilla.org/pipermail/es-discuss/2008-August/006905.html
[19:08] <peter_12_> xjs provides two functions "require" and "load". It may be possible to bolt "importModule" and "importFromModule" onto xjs
[19:09] <peter_12_> if the helma library files were written so they only use a single global object, then the user of a module would be happy with either the xjs or helma style
[19:09] <peter_12_> that is the code could be used both ways
[19:10] <peter_12_> it would not be a very onerous change on the helma code and would make it more flexible.
[19:11] <peter_12_> Not necessary to share infrastructure which is my main goal as I know these things are religious.
[22:35] <peter_12> zumbrunn: I read through that es-discuss thread and decided to get involved with that thread. I'd certainly like to make sure that whatever CPAN-like system is ready for the direction the ES group is headed. That may be difficult to guess and life needs to move along.

 

 

In the channel now:

Logs by date: