[dev] PEAR::DataObject

[Chuck Hagenbuch]

Quoting Jason Hines <jch@eyeintegrated.com>:

> Well, neat things could be done if all data was abstracted into
> objects.  Doing things like centralized administration for all Horde
> application in one admin panel would be possible.

Hmm. We _do_ abstract pretty much everything behind objects, but don't 
always map them directly to tables - managing complex table relationships 
using entity objects can bet pretty ugly.

Also, we simply don't assume that people will be using SQL for everything.

> Another good thing would be that Horde application developers would only
> have to define their DataObject configuration, and Horde could be
> responsible for the table creation, etc.

Having some automated table creation would be nice, I guess, but it's more 
overhead, and not especially fun code to manage it nicely for all databases.

> The Binarycloud framework abstracts all data through the use of
> Entities.  It's very nice.

I don't find this terribly convincing; I've looked at BinaryCloud in the 
past, and it is almost the complete opposite of Horde in how it mandates 
_everything_ and is in control of _everything_. There are of course some 
advantages to doing it that way - things are much simpler if you just 
_assume_ that every one of your users will have an RDBMS, etc. - but it's 
not necessarily better, or where we should go.

> I was just considering the fact that Horde extensively uses PEAR and 
> PEAR::DB, so I would imagine extending on that to utilize 
> PEAR::DataObject would be a good thing.

I'm open to being convinced that this is so, but getting specific - show me 
a piece of rewritten code that benefits from it or provides more features, 
show me that it's faster, etc. - would go a long way.

-chuck

--
Charles Hagenbuch, <chuck@horde.org>
"After a few minutes the most aromatic and nice smelling Italian coffee 
 will come out of the exhaustpipe." - Our stove-top espresso pot