Of course someone probably loves the quick-and-dirty nature of the Berkeley DBM's, but I think DBI is better even for lightweight stuff. The coding/execution overhead isn't that much greater and later on it's trivial to switch out DBD::CSV with something more serious. Going from *DBM to DBI on the other hand requires a huge rewrite. Better just to encourage people to do it the DBI way to begin with, and putting those 2 modules in the core would go a long way towards doing that.

Yeah, but as someone who spent way too much time using SDBM and GDBM it would be nice if the Berkeley DBs were removed from the core

Just a note: SDBM and GDBM are *not* Berkeley DB's (DB_File is the standard Berkeley DBM in the core). And, by the way, DB_File (and the other DBM's) are exceedingly useful tools and should stay in the core. As for DBI/DBD, I'm for a leaner core and one or more (semi) officially recognized SDK packages containing database, networking, templating, et cetera.

I have to agree with Trimbach, although my original post has absolutely no intention to compare Berkeley DBMs with the "database" I mentioned. (That itself could be a very interesting topic for discussion, but that is beyond what I originally asked. Personally, I don't think it should be a surprise, nowadays, to see people differentiate Berkley DBMs from conventional databases.)

It is too far from a good idea, to encourage newbies to start their database adventure with Berkeley DBMs.

When you learn, you start from the point where fits with your time in the history.

"no matter their obvious utility."

Hm...is it not true that, at least up to this day, there are more people need database access than people who need SOAP? but yet we have SOAP modules in core.

Update:

See below chromatic's post for some interesting facts.

but yet we have SOAP modules in core.

No, you have SOAP modules in ActiveState's distribution. That's not the core. So far, no pumpking has included an XML processing module in the core — so, no SOAP, no XML-RPC.