 |
Google Calendar Offline Talk and Demo
Posted by davidvc on October 05, 2006 at 10:37 AM | Comments (5)
Well, now that it's working, I think it's pretty cool. I have this great little example app showing how you can use Apache Derby embedded in a browser to store Google Calendar events locally and then ship them back to the Google Calendar server (using the Google GData/Calendar APIs) when you get back online. It handles automatic detection of the network going down, browser crashes and conflict management (e.g. when someone else edits the same event you updated while offline).
If you're coming to ApacheCon, I'll be showing it off there as part of my talk. Some time after ApacheCon I plan to make the code available and write something up describing how it works and the principles it is demonstrating. My goal is that this is one more step to help you, the developer, understand how to build an offline app, and what the various challenges and issues are around this.
Thursday afternoon at ApacheCon is actually going to be a real Derby Derby. There are a four, count them, four back-to-back talks about Derby that afternoon.
- Rick Hillegas is going to show the power of being able to put Java code in your database.
- Dan Debrunner is going to talk about our brand new release, Apache Derby 10.2, and what new features you'll see in there.
- Then there's my talk on how to build an offline app.
- Finally Olav Sandstaa is going to discuss techniques for understanding and improving Derby performance.
Good stuff... Your head will be buzzing with SQL statements and you'll be dreaming of btrees if you attend all of these sessions :)
So, hope to see you at ApacheCon next week. Stay tuned to this space for more information about this new example application in the weeks that follow. Cheers!
Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
It would be interesting to see an equivalent using IE persistence (long time feature) and Firefox 2.0's support of WHATWG's storage spec. Probably within a year most Firefox users will have upgraded. (Or didn't someone build an abstraction layer on this that supports various storage back ends including Flash or could be Java, also, I guess?) I still think that if I want to use Java storage specifically, I'm likely to use a Swing UI. But maybe that's just me. Anyway, still sounds like fun.
Posted by: tompalmer on October 06, 2006 at 08:47 AM
-
I looked at IE persistence. The problems as I see them are:
It is proprietary to a single browser (albeit a popular one) and portable only to Windows machines (and I guess Mac if you're running IE on Mac)
It provides no security. Java DB allows you to encrypt your data
It is not transactional, as far as I can see, which means no automatic crash recovery, no isolation for multiple threads, etc.
It is XML-based, which is OK, but for richer systems query and join functionality are important
I have heard about WHATWG, and it looks very interesting. The Mozilla implementation is using SQLite, which is great - a real database. It's nice that WHATWG is a standard, versus a proprietary API specific to one browser vendor. I don't know the roadmap for getting WHATWG implemented in other browsers. I talked to Benjaim Smedberg, and we had discussed Derby being an implementation for WHATWG storage for non-Firefox browsers, but that's something out of my scope right now...
That said, IMHO a key/value pair interface can only take you so far. Sooner or later you're going to need queries and a flexible data model and secondary indexes and the like. Maybe for a significantly large class of applications key/value is sufficient. There is a reason Berkeley DB is popular. But what I have seen happen pretty regularly with folks using BDB is that at some point you need more, and you end up building your own data model and querying and indexing on top of the basic key/value interface, and you write and debug a lot more code than you would have to had you started with a relational database. A relational db can support the key/value model, but it can also go beyond that.
The Storage interface for WHATWG also does not appear to have any kind of transactional interface to allow you to define transactional boundaries around units of work. This can be a problem. Even in my very simple sample app I needed a transaction around two separate persistence operations. Without this you can't guarantee the consistency of your store if multiple threads are accessing it (which I have seen happen even in a single DHTML app) or if your browser crashes.
I do hope that the SQLite being shipped with Mozilla 2.0 has support for encryption (their web site says you can get an enhanced version which supports ecnryption) and there is an interface in WHATWG for encrypting your data. This can be a real issue for some folks.
What I would like to see is a persistence model for JavaScript objects. This includes the ability to get and put JavaScript objects, as well as the ability to query, very similar to JPA for Java. There's no reason JavaScript developers have to learn SQL just so they can get the power/flexibility of queries, joins and transactions.
To be honest, I have to agree with you that Swing and Java Web Start can be a more elegant solution when you are using Java. The techniques I will be demonstrating here for offline storage and synchronization apply just as well to a Swing app as an AJAX app. But there is a swath of the developer community who would like to get real transactional, queryable, portable storage into their apps, but for whatever reason want to deliver a JavaScript app rather than a Java app. I'm trying to show this is possible...
Posted by: davidvc on October 06, 2006 at 09:42 AM
-
Thanks much for the detailed response and analysis.
Posted by: tompalmer on October 06, 2006 at 10:55 AM
-
The AJAX MAssive Storage System (AMASS) might be of interest in this context?
David, how to you talk to Derby from JS (if that's what you do), server-less?
Regards, Michael Vorburger.
Posted by: vorburger on October 23, 2006 at 02:37 AM
-
Hi, Michael. Nice to see a standards around basic key/value storage for AJAX. Note it does have the limitations I mentioned above, that it's key/value based and that it is not transactional. This may or may not matter to you, but something to be aware of.
How do I talk to Derby without a server? Well, that's one of the key benefits of Derby - it is embeddable and doesn't require a server. I just talk to Java code directly through LiveConnect, which then uses JDBC to talk to Derby embedded in the same VM. Code coming soon...
Posted by: davidvc on October 23, 2006 at 09:17 AM
|
java.net RSS Feeds
