Home Messages Index
[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index

Re: [wp-hackers] alternative database support

  • To: wp-hackers@xxxxxxxxxxxxxxxxxxxx
  • Subject: Re: [wp-hackers] alternative database support
  • From: Roy Schestowitz <r@xxxxxxxxxxxxxxx>
  • Date: Sun, 08 Oct 2006 16:20:29 +0100
  • Delivery-date: Sun, 08 Oct 2006 16:20:30 +0100
  • Envelope-to: s@schestowitz.com
  • In-reply-to: <4528DEF2.3020704@mullenweg.com>
  • References: <1160201374.6135.2.camel@sled10-laptop.mdcom-network.com> <FC8E41DC-51AB-4D6B-BBF9-D845749B0223@ftwr.co.uk> <20061007162148.1latga5o568sog00@banana.catalyst2.com> <4528DEF2.3020704@mullenweg.com>
  • User-agent: Internet Messaging Program (IMP) H3 (4.1.3)
___/ On Sun 08 Oct 2006 12:20:18 BST, [ Matt Mullenweg ] wrote : \___

Roy Schestowitz wrote:
Maybe it's worth inclusion in some FAQ under wp.org...? Also, it's bound
to become a serious problem from a political and a technical point of
view. I recently discussed this elsewhere, also in the context of
WordPress < http://tinyurl.com/s7kbt >. The sooner people get choice, the better, IMHO. Transparency is among one of WP's selling points. *smile*

More options does not make something better. With rare exceptions, the cost of the options often outweighs their benefits.

Your side in this debate makes perfect sense (in isolation), but please allow me to play devil's advocate. I know for a fact that I am not alone in this stance. This debate is also related to hidden options and preloading of functionality (with or without plugins). I'll present some counter arguments.

WordPress doesn't do anything that fancy with the database. There is
feature-comparable software driven purely by text files.

Very true, but these scale badly.

I used to be fairly enamored with the idea of DB-independence, but then
as I tried it I found the entire concept to be a farce. I have the same
level of interest of making Oracle, Postgres, DB2, a part of core WP as
I do having the program also run in Perl, Python, ASP, Ruby, and Erlang.

P/L's and DB's are very different. There are common interfaces for databases (e.g. SQL) whereas P/L's are more 'fluid'. There are also ambiguities that make transition/conversion a non-deterministic process. So while the comparison is convenient, research contradicts it. Languages are unified by their FSA's, but finding correspondence at a higher level is infeasible. Moreover, there are different paradigms and, contrariwise, while some databases are object-oriented, they preserve the same interfaces.

It's theoretically possible, and even attractive if you imagine *how
much larger* our userbase could be if we simply supported every
conceivable server configuration, but at some point the costs add up:

1) Infinitely more complex testing (we have enough trouble with W/LAMP)

If you use the strategy pattern, then not only will you attain good modularity, but you will also make testing more 'distributable'.

2) Same for debugging


3) Non-trivial overhead in code

If done tactfully, the effect of this can be mitigated.

4) Much slower development (WP Vista in 2008!)

True. But if you can expand/divide a team to work in a non-interfering fashion, then you never deal with 'code spaghetti'. Vista (formerly Longhorn), on the other hand, was scraped in October 2005 because the code was not modular. It still requires 60% of its entirety to be rewritten.

5) No visible benefits to regular users

"Regular" raises a brow. A more open set of options could appeal to more people who seek to integrate WP with something else. And there is also something to be said about security and monoculture. WP has had security breaches in the past.

I will be the first to admit that it is entirely luck that WP happens
to be attached to the most popular and fastest growing database in
history, and written in the most successful server-side scripting
language, but let's not throw away so lightly the benefits to
development the luckiness in our platform choices provided.

Lastly, as someone pointed out, $wpdb is structured as such that all
the hard work could be done as a $wpdb replacement with some clever
regex, with no core modifications. (Aka, a plugin.)

The relatively mature WP ecosystem has generally shown that development
closely follows market demand, where WP has lagged behind people's
needs (image handling, tags) dozens of plugins have sprung up to fill
the void.

All that said, the one other DB I would see as interesting in the
context of WP would be sqlite, simply because it is so small and light
and simple that it could potentially be run in places where any normal
DB system would be prohibitive, like a Linksys router. Also its
bundling with OS X and a future version of Firefox (maybe?) opens up
even more possibilities for the use of WP as a standalone desktop app
for personal use and/or development. How small a desktop download could
we squeeze a self-contained light web server + PHP + WP-sqlite into? I
have no idea if that would actually work, but at least it'd be
something compelling and different than anything easily available
today. However now I'm daydreaming and we should probably start another
thread if we're going to discuss that.

Okay, but here you seem to justify what earlier you described as a repellent route. This could develop to become akin to GNUzilla or IceWeasel, or forks like Flock or Swiftfox. I am aware of similar projects such as LightPress that emerged to address other types of demand. Maybe it's something worth thinking about... *smile*

Best wishes,


Roy S. Schestowitz, Ph.D. Candidate in Medical Biophysics
http://Schestowitz.com  |  GNU/Linux  |     PGP-Key: 0x74572E8E
http://othellomaster.com - GPL'd 3-D Othello
http://iuron.com - proposing a non-profit search engine

[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index