“Graphics on the Web: Going Beyond Images and Rectangles”

It’s on June 11(next Thursday) at Apple.

Thanks
-Sharon

create data: http://vnjs.net/?id=1000000069
insert: http://vnjs.net/?id=1000000077
update: http://vnjs.net/?id=1000000079
delete: http://vnjs.net/?id=1000000075
select: http://vnjs.net/?id=1000000078
……
and select HTML element from DOM:
http://vnjs.net/?id=1000000082

end link to download my framework: http://vnjs.net/www/src/kombai.rar

…but can someone tell me why you wouldn’t use strictly hierachical storage on a *client side* database? After all the client is going to be dealing with the data purely in terms of its own object hierachies. There aren’t going to be any of the sort of curve balls thrown at it that you get in a “bigger” SOA type environment.

SQLite has a rock-solid storage engine under the covers. They have integrity checks and rollback journals. It is very hard to corrupt the SQLite data file. Any other solution would have to do a lot of work to get the same ACID characteristics that SQLite has.

Back in the dark ages before the internet, but after flushing toilets, simple databases with the same philosophy as CouchDB, SimpleDB, BigTable, Berkeley etc.were the norm. Over time, people discovered that they were writing reams of code because the databases did not have the building blocks to avoid various kinds of data duplication, and the duplicated data had to be kept in sync, and kept searchable. Eventually people like Codd and Chen characterized the styles of data duplication and figured out how to avoid it through the various normal forms for program data. They also developed SQL as the building blocks for describing and manipulating that data. SQL allowed applications to become much more powerful and feature-rich without having to write proportionally more code. I have seen various data query languages come and go. Most came to reduce the “impedance mismatch” between the object world and the relational world. They go because eventually the owners realize that it would be too much work to give the customers the SQL that they really want.

As a side note on query languages, I have been watching the Ruby On Rails/ActiveRecord language. ActiveRecord was originally designed as a object-relational-mapper so that the designer could avoid the complexity of SQL. However, with each subsequent release of Rails, they have put in more and more features into the ActiveRecord query language that are rip-offs from SQL. I can’t wait until Rails 6 when they admit reality and support inline SQL. :) I have to give them credit though; they do provide an escape hatch to SQL if their query language is not powerful enough.

On performance, most PCs have enough horse-power to cough up a few cycles to the SQLite VM. I know that when our old company (Adscape Media) built the in-game advertising engine we put SQLite into the client-side code (linked into the game software), and there were no performance issues that caused our acquirer (Google) to yank SQLite in favour of JSON, XML, or whatever. If SQLite can be the client-side backing store for a video game, I would say it is fine for a “thick” web app.

On the “public domain” issue, if you want a license for SQLite, Hwaci software (co-owned by Dr Hipp) will be happy to provide you a license for a small fee.

Will JSON be the final format? I hope not because I would like to start carrying enhanced messages, a-la RDF (http://en.wikipedia.org/wiki/Resource_Description_Framework) with triples for example…

1. Identify data through URL
2. Operate on data with HTTP methods
3. Provide JavaScript interception on XHR (just like Apple provides Objective-C interception on NSURLRequest and URLMON provides Asynchronous Pluggable Protocol).

Read more about this and related work at Oracle on my Web site http://o-micron.blogspot.com

I don’t think that the argument holds that RDBMs are good because people already know how to work with them. The HTML5 database API really is a new programming paradigm for many programmers because all operations are fully asyncronous. This makes buildings things like ORMs even harder because now you also have a method call impedance mismatch.

What has worked really well for me too within the Joose world was to simply serialize objects to JSON and and simply deserialize them to JS objects on the next page view (with a jsonpickle-like protocol)
http://joose-js.blogspot.com/2008/08/automatic-serialization-and.html
This works quite well for non-so-large datasets that do not need concurrent access from different browser windows (OK, thats a small subset of applications)

With respect to bespin: I have a near 100% compatible HTML5 on Gears API ready. If we need it we could finally add a Joose dependency to bespin and use it or I could spend the 5 minutes on porting it to native JS :) Together with our WorkerFacade it would probably really easy to make this actually async under Gears. This would enable us to do DB operations on the main page without having to worry about UI block under Gears.