Related link: http://www.oreillynet.com/pub/a/network/2005/04/11/rsdp.html
Every now and then I see a proposal go by for something I’ve wanted for years. Today, it’s the Really Simple Database Protocol.
I am not an enterprise developer. I rarely give a damn about scalability beyond five simultaneous users. I’ve argued in the past that developers need to look beyond scalability, and I’ve argued repeatedly that simpler solutions make a lot more sense for a larger group of people than do highly sophisticated but deeply complicated (think Web Services, EJB, etc.) systems that try to solve every problem.
The Really Simple Database Protocol, from my perspective, is close to perfect. It runs over a verbose but trivial protocol, relying on well-known tools (XML-RPC and SQL) to do simple tasks. The relational database on the other end lets me work with large volumes of highly structured data, and it doesn’t matter (outside of SQL details and features) what database is on the other end of the connection. Nor does the database need to know much about the client.
Yes, there are performance issues, especially if you hit such a server with a few thousand SQL queries simultaneously generating large volumes of returned data. Using HTTPS increases the processing cost, while using HTTP leaves authentication data unguarded. Binary files transferred via XML-RPC become extremely verbose.
Sure, hitting your head against this wall will hurt. If those problems affect you, don’t use this. For those of us who just want to connect database A to client B with a minimum of fuss, this is just the duct tape I’ve been looking for.
Is duct-tape okay, or do we need to solve every problem with titanium alloys adhered with high-strength epoxy adhesives applied using precision robotics?
I like duct tape, but I already have some.
I'm a big fan of simple solutions when they're appropriate, but I'm having a hard time seeing why RSDP wins over ODBC. ODBC is widely supported on various platforms, provides a backend-independent way of sending arbitrary SQL to a database server, handles the complicated bits (blobs, etc.) without mostly getting in the way of simple queries, and even has its own set of efficiency issues to complain about.
Yes, any client language/environment that wants to talk to a database via ODBC needs to implement an ODBC-speaking extension, but so would any database that wants to listen for RSDP requests, so that seems like a wash.
ODBC is pre-tangled duct tape
And I can't say I'm any more excited about the prospect of using ODBC over a network than XML-RPC.
I've never liked ODBC, can't say I ever will, and think it tries to solve too many more problems than RSDP, at least for what I need.
The only major plus I can think of for ODBC is that it's widely deployed. That usually wins, of course!
ODBC is pre-tangled duct tape
Of course ODBC has issues. It's been implemented & deployed.
RDSP is just a napkin-fantasy.
ODBC doesn't fit on a napkin
Complain if you want about RDSP being a fantasy, but it definitely fits on a napkin. ODBC is a lot larger, and it's not just its implementation and deployment that make it more complex.
It's good (if surprising) to know that there are people out there who actually _like_ (well enough to defend, anyway) ODBC.
RSDP versus ODBC in Python
The problem with ODBC is that is fairly complex, and is not easy to deal with if the target machine that will be running the application is not already configured to use it (e.g. had all the necessary drivers installed, etc).
With a consistent XML-RPC interface, none of this middleware is necessary. You can use XML-RPC to submit the query across the wire and get a recordset back. In Python, XML-RPC is in the core library, so I can do this in three lines of code (sans error trapping, etc).
from xmlrpclib import Server
db = Server("http://db.foo.com/rsdp/")
xmlrs = db.rsdp("books","guest","password","sql","SELECT * FROM 'books' WHERE author = 'Brian McConnell' ORDER BY pubdate;',false,"xml")
The point here is that with an interface like RSDP you can write lightweight programs that do not require the target machine to be explicitly configured to talk to a database server. The problem with current DB tools is that the machine running DB-aware scripts needs to be configured to talk to the chosen back-end. With something like RSDP, it will be possible to write DB oriented programs without knowing nearly as much about the machines they'll run on.
At present, every time I get involved in a database project, I spend the majority of my time troubleshooting the database environment, and a minority building and maintaining my application. This ratio should be reversed, with database connectivity involving little more than looking up the URL for the database service, invoking an RPC call and capturing a result.
It's not that I like ODBC--I don't--
But it's in place on most of the machines I use, and available for most of those for which it's not in place. I can go work with it right now, and that's very important. It's a similar situation with JDBC.
ODBC doesn't fit on a napkin - true
Part of my point is that it's possible to "throw out" an idea that'll be simple (enough to fit on a napkin, as you say); the issues will arise when the idea is implemented and integrated!! C'mon, you've been around computing, you know there's no free lunch. Simple solutions (eg, XML-RPC) require too much customization work, and non-simple solutions carry a lot of weight that many projects don't need.
I don't have experience with ODBC, but JDBC, which I believe is similar. Again, idea of JDBC is simple. Devil's in the details...
Simple problem, simple solution
RSDP wins over ODBC (and JDBC) in the problem space for which it is designed -- simple, low scalability database access over the Web.
Obviously ODBC and JDBC win hands down for any enterprise-level applications due to scalability alone, but they're not a good choice over the Web due to the many calls required by the low level of their APIs. RSDP allows you to make a single call and get the results back in a single document, which is sufficient for a lot of applications.
One solution to implementation problems is for someone to simply write an RSDP implementation over ODBC or JDBC. It would take far longer to write the configuration code than the database access code.
The problem then is who would actually be willing to deploy it. How many useful databases are out there whose owners are willing to open them up to public perusal?