If I was using titles, this post would be called "There and Back Again: A Bonehead's Tale."

So, one thing lead to another and I've reverted back to PEAR::DB. The real deal-breaker was when I realized that the Google API Class that I wanted to use required PEAR::SOAP. This is a dilemma unto itself, because my precious Debian doesn't ship PEAR::SOAP in it's php4-pear package. Who wants to hassle users with dependencies?

Going back was much easier than going forward thanks to RCS. It wasn't as simple as a checkout, because I'd added some functionality since the change, but it was much more simple than I'd expected.

Now to decide if phpHtmlLib's validation is useful enough to battle the learning curve.

And after seeing this I'm half tempted to rewrite the damn thing in Bash!

It must be me. I must be doing something wrong.

I decided to forge ahead with ADOdb, despite the increase in memory. I finished the "porting" from PEAR::DB to ADOdb and decided to play with another thing that's been on my radar lately: phpHtmlLib.

Since I was just starting out, I only changed a couple of error screens (empty view and no view cookie set) to use phpHtmlLib. It was very easy to get nice, formatted, valid xhtml. What I couldn't believe was that my memory usage jumped to an astounding 6253080!! (Remember that pre-ADOdb and pre-phpHtmlLib, my memory usage was 2637208 and that's even with the reportedly bloated PEAR::DB!) And that was after I commented out the XMLTagClass.inc from includes.inc in phpHtmlLib.

Maybe I shouldn't worry about it, or I shouldn't trust the output of Xdebug. It just seems quite close to the default 8M limit for PHP processes and I still have a lot of stuff to implement!

What a disappointing weekend! I spent quite a bit of time porting from PEAR::DB to ADOdb after reading how lousy PEAR::DB was and how great/fast ADOdb was. I also set up another instance of PHP with Xdebug.

According to Xdebug, my old code using PEAR::DB was not only faster, it used less memory! xdebug_memory_usage() reported 2637208 for the old code and 3113928 for the stuff linked to ADOdb.

Granted, there are things I could probably be doing better, but basically I was changing $db->query($sql) to $db->Execute($sql) and nextID() to GenID();. Dumb enough to be monotonous, smart enough that I couldn't just do it with sed.

I still haven't decided if I'm keeping the port or just sticking with what I had, which makes it difficult to move forward.

So I was reading Harry Fuecks' Sitepoint column and the comments talk about how great PEAR::DB is with regard to SQL injection attacks because one can make use of prepare() and execute() for avoiding common SQL injection techniques.

Great! I want to avoid SQL injection attacks. Sign me up!

So I spent the better part of a couple of evenings retrofitting DMR8's aliases library to use prepare(),execute() and, in some cases, autoPrepare(). I found the documentation to be quite confusing and had to do a lot of experimentation to try to see just how things worked. The main problem with the documentation is that it's not specific nor thorough enough. A secondary problem is the lack of user comments, which are very helpful with the PHP documentation.

As I'm perusing the documentation, I wondered what other PEAR::DB functions I could be using to make my life better. DB_common::limitQuery()?! What's that?!

As it turns out, using "LIMIT" in SQL won't necessarily work with all datbases, so the database abstraction layer must monkey with your SQL to make it work across the board. So does this mean I can't use my precious prepare()?! After much looking around, I found that, yes, it does mean that I can't use my precious prepare() when I want to limit the results of my query.

While I was trying to figure out about prepare() and limitQuery(), I found this short post by Harry Fuecks that linked to this longer and very informative post (and good blog!) which basically boils down to "PEAR does a lot of dumb things." I'd seen a lot of criticism about PEAR before and even PEAR::DB, but I figured that every project gets criticized and that the "probably installed" nature of PEAR would win out over distributing libraries along with my apps.

I also ran across this request for testing a release candidate for PEAR::DB 1.6 that lists "Several bugs related to limitQuery() were found and quashed." among the changes. As you might guess, version 1.6 is light-years ahead of the version that comes in the Debian Unstable package for php4-pear. While I realize that it's easy to upgrade, the whole point of going with PEAR::DB was its "probably installed," remember?

So after some deliberation, I've decided to switch to the much-lauded ADOdb by John Lim (who needs to learn about the <description> child of <channel> in his RSS feed... shorten that title, man!) ADOdb has a PEAR::DB emulation/compatibility layer, but if I'm going to use and distribute his library, I may as well use his calls. Btw, it seems that ADOdb's function SelectLimit() has the same problem -- no prepare() for it.

Maybe I'm just a big 'fraidy-cat, but I try to do LIMITs as often as possible because I don't want to screw up too badly. It seems like it would be easier to do so.

So now I'll spend a few days learning about ADOdb and converting to it. Then I can get back to creeping the featuritis. :)

While I'm being so long-winded, I'll post an update of what's going on:

• History
  • 70% done. Need to do some work on editing history entries now that {auto,}groups exist.
• Aliases
  • Done (and better than DMR7's)
• Bookmarks
  • 85% done. I think deleting groups is the only thing that hasn't been completed and that's 95% done.
• Groups
  • This is about 50% done and I'm concerned that it's going to be confusing for users in a number of different ways. Sound's great, huh?!
• RSS/ATOM
  • I've switched to using Magpie's parser, which supports ATOM as well. I've also written a script that can be cron'ed to keep rss feeds up-to-date so that you don't have to wait on DMR to do it.
  • Unfortunately, MagepieRSS is GPL'ed. I'm still looking for good information on dual-licensing (for my code) but I'm not finding much. I guess if worse comes to worst, I'll release DMR8 under the GPL, but I sure hope that I don't have to.
• Multi-User
  • This is about 70% done. I'm still trying to decide some things, so it's taking longer than I'd like
• Documentation
  • 0% done! Whoopie!

There are also quite a few things that are up in the air. I want to expand Notes to be the only place you'd want to notate something (but that's another (long) post). I want DMR to be able to cache web pages. I'd like to do some fun stuff with the Google API, but its beta status scares me a bit. And so on, and so on.