> This is the signal issue I mentioned. I don't believe it would be too > difficult to push signal handling to the client and pass events across > the wire to the server process. Interruption would be a problem, > especially since just killing the remote JVM would be unacceptable, but > JRuby already has mechanisms in place for terminating a running Ruby > app/script that we would hook into. And ultimately, it's just a matter > of being clever on the server with your Nails...but that's impossible to > do right now without signals coming over the wired.
I think I would have three stages (depending on how much integration you want in the NG server): - plain JVM class - main() gets called; NG default - JVM class with nailMain() - JVM class implementing some interface - interface could include signalledStop() > Yeah, I wouldn't expect NG would be something people would start up and > leave running for long periods of time. I'd expect it's something you > start up (or something that comes up with your IDE of choice, maybe?), > that listens only on loopback, and that you shut down when you're > through working. Maybe a more secure NG would be needed for some > applications, but I think making NG rock-solid (signals, etc) first > would be my priority. It is something I would advertise, though; it seems irresponsible not to. I do imagine developers may leave this running in the background (assume it can stay up for many hours, which in my experience is true). > Definitely less of an issue here; people will not be monkeying with > JRuby version. One thing that would need to be improved, however, is Yes, for a compiler or interpreter it's less of a problem, as long as the interpreter is checking for file modifications. It's just something that's bitten me in the past. > adding the ability to pass along the client CLASSPATH and set up a child > classloader for every Nail based on that CP. That shouldn't be too > difficult; you just make sure to start up the server with a > minimal/default CP, and then the additional CP gets tacked on for every > Nail. And this too is largely already possible, since it's sending along > env vars, but I'm not sure whether NG is using separate classloaders yet. Sounds like a good feature. > Not a bad thought, but I'm not sure the requirement to have a C-based > scripting language installed is much better than requiring a compiler be > installed as is the case now. In our case, we can't even count on Ruby > being present; there are *lots* of people who have explicitly requested > that JRuby never require Ruby be installed. Actually, I was thinking of compiled Python, to avoid maintaining the ng.c file in case it needs to be extended. The deliverable/installable would still be a binary, just what would be maintained is something in Python. > That's actually a good idea...as long as that server could be really > minimal. Every app server I know of takes at least 50M of its own memory > before even starting up your app, where my little JRuby NG server starts > up in about 25M. But the manageability, security, and reliability of a > real app server would probably outweigh the costs, and a fast network > engine like Grizzly could help apps that are going to crank out a lot of > content. Ideally we could move code between containers, NG being the simplest form of the container. I'm not married to the idea, just that Marty wrote a bunch of code that's already handled, for other reasons, in these app servers. The real meat of NG is the client and the simple protocol, IMO. Of course, having a small server available is also cool. > GlassFish would be my choice for this; for the experimental > GlassFish-Rails "gem" they've managed to strip it down to a few MB, > which is really impressive, and the GlassFish v3 kernel is widely touted > as being only a few hundred kb. Yes, it's also received a redesign in the recent past, which in this case I think is a plus. > I agree. Have you ever communicated with the folks behind NG? I'd rather > not fork it, but I'm not getting responses to any emails I send to their > mailing list, and the whole of Martian Software Inc appears to have gone > quiet since late 2006. Yeah, a couple of years ago (2004?) when Marty was still actively working on it. Those older mailing lists appear to be gone, not sure if they were previously hosted on Sourceforge or on Marty's website. I can't see any reason not to fork (or rather, pick up where he left off) since it's been out of active development for over two years, and never moved past version 0.7. Seems to me that starting with NG and focusing on specific features important to JVM language writers (including many on this list) would help the tool grow in new and useful ways. Most JVM languages, esp. those with an interpreter, would get a boost (was my experience with BSH, for example). Note that the Scala folks also have a server-based compiler called FSC; might be interesting to see if there's any overlap there. Patrick --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
