The main addition to version 1.0.6 is support for SQLite3. I've changed the design a bit so the code in my previous entry is not accurate (if you want to see an accurate example, just check the home page or better yet - download the framework and try it.

I'm in a dilemma regarding which plugins to add next. Adding additional database plugins such as MySQL, PostgreSQL, Firebird etc. is trivial (just need to change less than 10 lines of code since the database plugin is built on the excellent SOCI database abstraction library).

I also want to extend the sockets plugin to include access to many additional OS features, and also to create a language bridge plugin that will enable writing JNEXT plugins in any language (including scripting languages).

However - all this will have to wait as I've just discovered a problem when handling NULL values in SQLite3 databases, so I'll first fix that and then get back to the dilemma...


[ add comment ] ( 1 view )   |  permalink  |   ( 3 / 39 )

---

I've completed testing the new JNEXT extension which will support accessing all major databases (MySQL, SQLite3, PostgreSQL, Oracle and others) locally from JavaScript within a Web browser.

Still need to get the packaging complete but I hope to release a new version of JNEXT some day next week. Meanwhile here's a sneak preview of what you can do:

<script language="JavaScript">
    myDB.query( "select * from ex" );
    var row;
    while ( (row = myDB.getRow()) != null )
    {
        strHTML += "<tr>";
        for (var i=0; i<row.length; i++)
        {
            strHTML += "<td>" + row[ i ] + "</td>";
        }
        strHTML += "</tr>";
    }
</script>


[ 2 comments ] ( 25 views )   |  permalink  |   ( 3 / 40 )

---

I thought of implementing Mac OS/X support first but getting my hands on a Mac OS/X system has been delayed... if there are any OS/X developers out there that want to take on the task - please contact me.

Anyway, the next step is creating an extension for database support, which will include all major databases. After that, support for additional socket types.

Good things are coming your way :-)


[ add comment ] ( 1 view )   |  permalink  |   ( 3 / 57 )

---

Recent technologies such as Adobe's AIR, Microsoft's SilverLight and Google Gears show an interesting (and in my opinion, welcome) trend in better utilizing the processing power of the desktop client. I've read articles praising the thin client model over the fat client model and also have seen articles advocating the fat client model, while debunking myths about the advantages of using thin clients. As is many times the case in these sort of arguments, the truth depends on the application, and the correct path is usually finding a correct balance of both methodologies. However, for a long time there was not much freedom to find that balance due to lack of client side technologies for powerful and stateful browser applications.

This is why I feel that the technologies mentioned above are finally a step in the right direction. So if we now have these tools, you then may ask why was JNEXT created ?

There are four main reasons:

1. The first working version of JNEXT (it wasn't called that at the time) was written before any of these technologies was publicly available. Due to my involvement with other projects at the time, I just never got around to packaging it properly and making it publicly available.

2. I suspect that at least one of the technologies mentioned have some sort of commercial agenda which will eventually conflict with interoperability (you can probably guess which), so there is a risk that using that technology, might limit the scope of your efforts to the confines of that agenda. JNEXT has no agenda other than offering developers more freedom to decide how to divide the processing load between the Web Client and Web Server.

3. Simplicity. A turnoff for me in any technology is unnecessary complexity. JNEXT provides a fast learning curve for both using existing JavaScript native extensions (as can be seen by looking at the short sample in the home page) and developing new extensions. This again was influenced by my experience of time wasted understanding unnecessarily complex API's or searching for good samples.

4. Another thing I dislike in frameworks is unnecessary bloat. With JNEXT, keeping a small footprint was an important factor. The size of the bridge component that connects JavaScript to the native code is 204K for the NPAPI version and 384K for the ActiveX version (in version 1.0.5). The size of the native extensions this bridge loads depends on how the native components are implemented but you only need to load the relevant extensions for your application's purpose. The size of the JavaScript extension framework is 3K with an addition of around 3K on average of JavaScript wrapper code for every new native extension.

I hope you'll find JNEXT helpful for your applications and hope enough developers will extend it with new and useful extensions. The goal is to give more power to developers and any contribution is always appreciated



[ 2 comments ] ( 73 views )   |  permalink  |   ( 2.9 / 60 )

---

Whew - documentation and packaging have been completed (at the expense of my sleeping hours...)

Anyway, version 1.0.5 contains many improvements and the sources contain everything for anyone who wishes to write new extensions.


[ add comment ] ( 1 view )   |  permalink  |   ( 2.9 / 68 )

---

<<First <Back | 1 | 2 | 3 | 4 | 5 | 6 | 7 | Next> Last>>

No Footer - Page Generated in 0.7974 seconds | Site Views: 12501