Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

fansipans (7678)

fansipans
  (email not shown publicly)

Journal of fansipans (7678)

Sunday October 05, 2008
09:55 AM

Using Data on the Web - Models, Persistence, Management

[ #37602 ]
Originally posted to my blog.

I've been drowning myself in jQuery and HTML+CSS at work, which has been awesome for coming up to speed with all the recent technical developments on the web.

One thing that has piqued my interest quite severely is the integration of JavaScript with server-side environments. With a tighter binding between client and server code, we can write less code, have better test coverage, and truly refactor web applications across everywhere their business objects/rules live.

After rediscovering Joose (one of the guys on use.perl wrote it or helps write it I believe), and seeing one of their demos where Joose uses GoogleGears or HTML5's Database feature, I really wanted a simple-to-use ORM for JavaScript. Without GoogleGears or HTML5 support this could also easily be done server-side by having a url that took standard orm requests (find/search/save/delete) and returned standard JSON.

Now this sounds familiar.... oh right, that's a perfect description of CouchDB!

CouchDB is another thing I've had a lingering fascination with. It is a document-based database written in Erlang, with a JSON interface. Data manipulation inside the database is performed by snippets of code that create "views" of the data. CouchDB ships with JavaScript support, and support for Perl exists in CPAN via CouchDB::View. It's one of those things you can see has HUUUUUGE potential, but really needs those little libraries that link it to other popular frameworks/platforms to really take off, or get that foot in the door with the web programmer zeitgeist.

So according to this mailing list thread about work on Joose.Storage which mentions CouchDB and this announcement that Joose supports the cross-platform serialization library "jsonpickle", I wonder what it would take to get that perfect easy API so in a Joose class all you'd have to add to your Joose class definition is:

does: CouchDB

That and maybe adding something like (totally making this up)

Joose.Storage.CouchDB.url="http://db.server.org/testing"

to the top of your javascript, and badabingbadaboom you've got versioned object persistence backed by one of the most awesome open-source high-performance databases out there!

Edit: Looks like there's already a jQuery CouchDB plugin, written by Jerry Jalava (see announcement on his blog.) It looks like a straightforward implementation of the CouchDB API:

create(database_name)
connection(database_name | view_name)
get(document_name)
save(database_name, document)
all(database_name)

I'd like to see a database-backed object persistence layer that can use that API, or a number of other APIs, such as:

1. A server resource/URL that receives the name of a database operation, and a JSON representation of the data. This is nice because it's easy to implement with whatever server database / language / runtime you have. If this were a centralized project, it would be trivial for members of the community to support new server environment/database combinations.

2. JSON-enabled Database Servers. Who wants to write the MySQL Server JSON connector? Or a generic JSON-to-Database bridge, which could support a standard JSON interface, and many different backend databases? The bridge could be configured with even more javascript to function as server-side validations or business logic.

3. SQL Dispatcher. Pretty much the same as #1, but with the SQL generated client-side. This would still provide a JSON interface, and require parameterized queries.

It seems to me that all of these ideas have been best expressed by CouchDB, but to acheive widespread adoption, I still have concerns with legacy systems, existing infrastructure, critical mass, etc.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.