Note: if we had DRY working for blogs, then I could have just embedded the content from my other blog and not have had to enter things in twice. Posting a link is not the same as having the content immediately available, which is why I decided to just copy the blog. Oh well...

You may have noticed that I am very interested in how data is managed on the Internet as a platform, at a web scale. In that light, I have been having some very illuminating and interesting conversations with an old friend and colleague, Nitin Borwankar. His thoughts on data property rights and DRY data are concepts that if implemented could result in a major shift in how we manage data on the web.

Data property rights is about laying out a "bill of rights" for data that goes far beyond "the right to move". It also includes the right to access, modify, remove and own your data. So often it happens that once you upload your content to a site, you no longer have full rights to that content, as if somehow in the act of uploading it it is no longer yours. It's like living in a serfdom where you do all the work to plow, seed, tend and harvest the land, but the fruit of your labor is not yours, just because you are using the land that someone else owns.

DRY data is about following the principle of Don't Repeat Yourself for web content. Web applications need to start applying this principle, so that rather than you having to load copies of your content across multiple sites (and often losing some degree of ownership of it in the process), you place it in one location (your "home" on the Web, as it were), and then you refer application providers to that one place. They can focus on providing added value (for instance, referring it to your friends, enabling collaboration, or helping you organize it or present it in useful ways) rather than on the overhead of building and deploying a scalable storage architecture.

Nitin calls this architecture YINAS (YINAS Is Not A Silo).

The value of DRY for the user is obvious - I only have to put my stuff in one place, and I get to really own my stuff, rather than the vendor owning it. DRY is also very valuable for the vendor, as they can save overhead and complexity by delegating the work of scalable storage and indexing to a "data service provider" rather than having to do it themselves. It's even good for the environment, because you need fewer disk farms sucking up power and space.

It's funny, it makes so much sense, but nobody is really doing this.

I pulled Tim Bray aside at Java One to talk to him about these ideas after reading his blog about changing his address, and he suggested that concepts are good, but a simple proof of concept is better. Hm... let me think about that ... :)

I know this isn't my main blog page any more (I'm hanging out at http://davidvancouvering.blogspot.com), but I wanted to reach out to you all and get your input.

We are looking at what we want to do next with database tooling in NetBeans, and there are some features I'm just not sure how important they are. You can help guide the ship in the right way.

I have put together a very quick survey, no more than ten minutes. If you're so inspired, please check it out.

I've decided to move my blog to a new location. You can now find me at http://davidvancouvering.blogspot.com.

Why am I making the move? Well, this was a hard decision. I really like the java.net community, and I like how the editor takes care to call out cool and interesting stuff.

But the problem is, sometimes I want to talk about more than Java, and more than my work. And java.net really wants and needs to stay focused on Java technology and things that impact Java (like Ruby). If my blog waxes poetic about politics or the cutest thing my kid did the other day, it tends to diffuse the focus of this site. People come here for serious Java stuff.

I also am a little constrained by the fairly rigid walls of java.net as a blogging platform. Personally, I'm tired of typing in raw HTML. I want to have a few widgets, not many, on my page. I want Google Reader to show the whole post, not just the blurb. Things like that.

If you don't want to see cute pictures from time to time, or hear about my opinions on education, and you can subscribe just to the "technology" label. There's also a quicklink label, for useful delicious links that I have auto-posted to my blog.

So, see you at my new digs!

P.S. Yes those are probably the dullest photos on my "recent Flickr Photos" widget. But I promise they'll change from time to time :) (Most of you will probably be reading my through an aggregator anyway and won't even see my fun widgets. Too bad...)

Open source continues to amaze me. For so many years, I have worked on projects where customers would clamor for features, and we just didn't have enough time in the day or people to get them all built. We would say "yeah, that sounds cool" but with all the other things on our plate, when would we ever get to it?

Well, in open source, it's a whole different ball game. The latest example is the contribution of Egil Sorensen's master's thesis. Egil is a student in the Computer Science department at NTNU in Trondheim, Norway, and he has contributed code that provides replication and hot standby for Apache Derby (discovered through Max Mortazavi's blog).

This paper and attached source code describes the work done to add hot standby replication functionality to the Apache Derby Database Management System.

By implementing a hot standby scheme in Apache Derby several features are added. The contents of the database is replicated at run time to another site providing online runtime backup. As the hot standby takes over on faults availability is added in that a client can connect to the hot standby after a crash. Thus the crash is masked from the clients. In addition to this, online upgrades of software and hardware can be done by taking down one database at the time. Then when the upgrade is completed the upgraded server is synchronized and back online with no downtime.

A fully functional prototype of the Apache Derby hot standby scheme has been created in this project using logical logs, fail-fast takeovers and logical catchups after an internal up-to-crash recovery and reconnection.

In case you missed that, this feature provides basic high availability to Derby. This is not small potatoes, and it was done as an independent contribution to Derby. Wow.