Gearing up MySQL with Google Gears
« previous entry | next entry »
Jun. 5th, 2007 | 12:31 pm
The weather was great here in Seattle this last weekend. Nice and sunny,..
The Google Gears stuff is still on the brain :)
Pulled the source code to take a look at it. The database code is laid out in the "database" directory. It is split up for each browser, with a "common" directory (though little seems to be common). The code is written in C++, with an object type of "GearsDatabase" representing the database itself. The code is lightly commented, but the naming conventions make the code self readable. There is more database code then what is found in this directory though, so there is not a full encapsulation of the database code.
And the real question I wanted to answer for myself?
What about making MySQL work?
We could make MySQL work and reuse the Google code. Not cleanly though... there interfaces weren't written to make it a very clean implementation. We would also run into the problems of:
MySQL is client/server. Unless you compiled the database connect string you couldn't talk to a central database (which would make this interesting). If you did make it possible though... then you got a big old security loophole to work through.
There wasn't a security model built into the gear's layer for the database. This makes sense with Sqlite. It does not have any sort of ACL system internally.
I wish that the writer of the code would have used an abstraction layer, maybe the new one for databases found in the Apache APR. That would have made it a bit easier to integrate multiple databases. I wouldn't have picked ODBC, only because I would rather tell a user to stick a fork in their own index finger then explain how to get an ODBC driver working.
It is a shame that the Safari support isn't complete yet, if it was I would take a crack at doing a quick port. Its not though, and I don't have the time/tools chain to do the Firefox one quickly.
I was asked this morning during an interview if there were any specific open source projects that a smart college student should start.
I'd take the Google Gears code and re-implement it for multiple databases (ok... I'd just do it for MySQL personally). The code is easy enough to follow, and I bet it wouldn't be more then a couple of weekends worth of work to make it work with a couple of like designed databases.
Sounds like fun, I don't have the time :)
The Google Gears stuff is still on the brain :)
Pulled the source code to take a look at it. The database code is laid out in the "database" directory. It is split up for each browser, with a "common" directory (though little seems to be common). The code is written in C++, with an object type of "GearsDatabase" representing the database itself. The code is lightly commented, but the naming conventions make the code self readable. There is more database code then what is found in this directory though, so there is not a full encapsulation of the database code.
And the real question I wanted to answer for myself?
What about making MySQL work?
We could make MySQL work and reuse the Google code. Not cleanly though... there interfaces weren't written to make it a very clean implementation. We would also run into the problems of:
I wish that the writer of the code would have used an abstraction layer, maybe the new one for databases found in the Apache APR. That would have made it a bit easier to integrate multiple databases. I wouldn't have picked ODBC, only because I would rather tell a user to stick a fork in their own index finger then explain how to get an ODBC driver working.
It is a shame that the Safari support isn't complete yet, if it was I would take a crack at doing a quick port. Its not though, and I don't have the time/tools chain to do the Firefox one quickly.
I was asked this morning during an interview if there were any specific open source projects that a smart college student should start.
I'd take the Google Gears code and re-implement it for multiple databases (ok... I'd just do it for MySQL personally). The code is easy enough to follow, and I bet it wouldn't be more then a couple of weekends worth of work to make it work with a couple of like designed databases.
Sounds like fun, I don't have the time :)
(no subject)
from:
omnifarious
date: Jun. 6th, 2007 04:09 am (UTC)
Link
I should look at this. If I were going to do something like this, the first thing I'd do is put in some way to make sure that the data a website stored on your computer was only reachable by you and that website.
But, this kind of makes me nervous. I've wanted my data for years from 3rd party sites. One of my biggest blockers to using web applications is worrying about someone else having all my data and not being willing to give it to me.
The most obvious use I see for this is a way for them to have their cake and eat it to. They don't have to provide storage space for any of your data, and they can encrypt it so you can't get at it either. They hold the data on your very own hard-drive hostage.
Reply | Thread