Over the past days, I did some experimenting with the JOMP patch for Rhino and the mapping of additional filename extensions to HopObject properties. I probably took it a bit to far and made the list of supported file suffixes to long, even introducing duplicates, but I would like to propose supporting additional filename based conventions for Helma 1.7.
Here is what I added for my experiments:
foo.macro --> becomes a hobj.foo_macro function with "params" as first argument
foo.get --> becomes a hobj.foo_action_get function
foo.post --> becomes a hobj.foo_action_post function
foo.put --> becomes a hobj.foo_action_put function
foo.delete --> becomes a hobj.foo_action_delete function
foo.e4x --> becomes a hobj.foo_e4x xml object
foo.json --> becomes a hobj.foo_json js object
Then I also needed a mapping that would not be generally useful, but only interesting in the context of my experiments:
foo.control --> becomes a hobj.foo_control function with "view" as first argument
And on top of all that, I added some duplicates:
foo.view --> the same as foo.skin
foo.action --> the same as foo.hac
Maybe instead of adding direct built-in support for additional filename conventions to Helma, we could instead add functionality that would make it easy to script/configure such additional conventions as needed.
Besides a few new features, like the newly added res.resetBuffer() method and the ability to name type.properties files after their prototype, this update brings bug fixes in many different areas. See the
changelog
for the detailed list of fixes.
The new 1.6.1 version of Helma also includes an updated version of Rhino, with some E4X related fixes. The new packages now also include the
jala modules
and
updated documentation
.
At this point of course just a case of
totally unimportant historical Internet trivia
. The surprising thing is not that the Netscape browser will finally die, but that it was still alive until now. I hadn't noticed ;-)
From the comments on
the slashdot posting
... tieTYT tells an anecdote about what AOL did to Netscape:
[...]one of the things they did was realize that pop-up blocking was one of the new cool things for browsers to have. But the marketing team stepped in and said, "Hold on just a second. We can't have the browser blocking OUR pop-ups." So they added rule to block all pop-ups except those that came from the netscape web page.
The netscape homepage happened to have a pop-up on it and of course, this is the default home page of the browser. When you initially ran netscape, first thing you saw was a pop-up and the page behind it claiming, "New Feature: pop-up blocker".
You can't escape bad karma. What AOL does to Netscape, Time Warner tends to do to AOL. We'll see.
One thing that
Matthew King's comparison
doesn't mention is the 1024 byte per attribute value limit of
Amazon's SimpleDB
, which means it's really more an index for what you put into
S3
.
David Greenspan, JD Zamfirescu, and Aaron Iba have
released AppJet
. Like
OpenMocha
, it's a web-based soft-coding framework that streamlines the easy development and deployment of small web apps using server-side javascript and like OpenMocha, it's powered by Helma.
Unlike OpenMocha, they went the extra miles of making the framework very approachable by well integrating AppJet online hosting of your custom apps, by designing the framework in a way that I think developers used to PHP like environments will appreciate and by gearing it towards very simple, small apps at the beginning.
The key that enables a hosted app service like this to deploy many small apps from many users without fuss is to properly seal the server-side javascript environments of the different apps from each other. Security is the main factor there of course, but efficiency is the other. I've been experimenting with this a bit for a future update to OpenMocha and learned that it is trickier than I would like it to be.
No surprise then that this is exactly the area of their code that they consider to be their crown jules and that they won't be able to open source. They do intend to open-source the Javascript framework that runs within (and around, presumably) that virtualization. Actually, the source of the framework that runs within the virtualization
is already visible online
.
I particularly like the way they encourage appjet apps to be an open collection, in a sense becoming an appjet code library. That's an aspect that already was very successful in the
old days of WebCrossing
and that I think is an essential part of a web-soft-coding environment.
Indeed, facilitating easy code reuse and sharing is a focal point that would benefit the Helma community at large as well. I need to setup something like a code bin, where we can easily upload, categorize, search and find code snippets for reuse in other Helma apps.
Joshua Paine
has ported the
js lib for working with couchdb
from AJAX and crockford's json to helma.http and helma's json support. Definitely a candidate for inclusion as part of the modules in the next Helma release, I'd say. Now, if we use the onInit and onPersist hooks and suppress the embedded db, we could directly leverage all the fancyness of HopObjects for
CouchDB
, including the caching :-)
var c = new CouchDB('testing','localhost',8888);
c.createDb();
c.save({ title:'Testing', content:[1,2,3] });
Congrats! You just created a DB and saved a document in it.
Although I prefer the dynamic and flexible nature of Javascript to be taken even further instead of tying things down with classes, strict types and non-mutable built-ins, I see why ES4 is a good next step for ES as the "universal scripting language". ES should be able to bend all the way to where it becomes similar to a strict compile-time language. In a sense, the ability to be strict becomes the proof of its ultimate flexibility.
On the other side, I hope we can still get more features into ES4 that increase its dynamic nature. Maybe some of what Doug Crockford has up his sleeve with ES3.1 can still go into ES4 *in addition* to what the majority of
TG1
is already proposing. Yes, that would make ES4 an even bigger revision. After the amount of time that has passed since the evolution of Javascript has cooled down with the end of the browser war, a big revision is overdue. Client-side technology has again become a focus. As a result of the Ajax hype, Adobe's AIR and MS's Silverlight, the client-side is again becoming a battle ground.
So, churn TG1, churn. Bring us new ECMAScript revisions quickly. Don't hesitate to split things up into multiple specs, like you've done in the past with
Ecma-327
and
Ecma-357
. For example, a more flexible, less secure mode allowing embeddings to opt-out of the non-mutability for built-in types, offering macros and allowing even built-in keywords to be overridden can all make sense in some environments. So would a much more limited, more secured ECMAScript subset, defined as a separate opt-in standard, that could provide a jailed eval to embeddings that need it.
The use case in browsers is only a small part of the entire ECMAScript universe. Outside the world of browsers, maximizing flexibility can also mean to allow embeddings to run in different modes or to not require them to implement all ECMAScript subsets. So, not everything that is standardized under the name "ECMAScript" actually has to end up in web browsers!
