"I have a mind like a steel... uh... thingy." Patrick Logan's weblog.

Search This Blog

Loading...

Friday, November 14, 2008

Service Frame-querks

More from Patrick Mueller's sudden blogginess...

"The level of functionality we have today, provided by the browsers, for components/modularity of javascript code is <script src="">. Basically, all the power, flexibility, and functionality of the C preprocessor's #include statement (good and bad). But I'm looking at my calendar to see what year this is again. Doh!

The big JavaScript frameworks build their component stories on top of this, and the whole thing just gives me the willies looking at it."

http://pmuellr.blogspot.com/2008/11/javascript-service-frameworks.html

Patrick also mentions Java's service frame-querkiness with class loaders, jar files, etc. I don't know much about OSGi - which he and others suggest plugs some holes.

Dang. I agree these are issues. I am wondering though how simple a language can be, and fill the service frame-querkiness some other way. For one thing, language-level frame-querks don't play well together across multiple languages. Unless you cram them together into a single VM and make them all conform to some base-level language concepts.

Patrick heads in this direction when he writes about GoogleGears WorkerPools as a potential mechanism for better service isolation...

The great thing about the WorkerPool stuff is that it brings another dimension to the JavaScript story - separate environments / contexts / spaces. The ability to have a bunch of code running, separated into protected object spaces, with very explicit communication channels open between these spaces.
There is little that's language-dependent about that. And this lowers the burden on what must be "in" the language per se.

1 comment:

Patrick Mueller said...

Great term - frame-querks.

I'm not a huge fan of OSGi itself, but it's not terrible, it's good enough, and not sure if there's really any alternative in Java-land.

Good point on language neutrality, hadn't really thought of that. The messaging between workers in Gears is basically JSON-ifiable data. No pointers, no code, just simple data structures. Again, lends itself to literally any other language. Even if you're just dealing with what Gears provides, you could use a JS shim to talk to any other language via HTTP no problem; your non-JS language would be on the server-end of the HTTP pipe. Would be nice to avoid HTTP if not required tho ...

Blog Archive

About Me

Portland, Oregon, United States
I'm usually writing from my favorite location on the planet, the pacific northwest of the u.s. I write for myself only and unless otherwise specified my posts here should not be taken as representing an official position of my employer. Contact me at my gee mail account, username patrickdlogan.