Re: [Phpgroupware-developers] Ideas and plans

[Alan Langford]

Thanks for your comments. I will go in and make feature/suggestion entries 
as soon as possible.

At 2005 05 01 17:37, Chris Weiss wrote:
> > * Disconnect the database from the application with a similar services
> > model. This makes it easier to have a distributed database. It also makes
> > it easier to make the back end an array of supercomputers running DB2
> > clusters. ;)
>
> This could be done in our current model by either the sysadmin
> confuring his database libs to do it or by adding features to adodb,
> or in front of adodb, fr those databases that don't support in the
> libs.  However, the "right" way to distribute database is in the libs,
> not in the php.

I didn't express myself very well on this. Let me offer an example. I am 
working on an e-comm site, which I want to make as flexible as possible. 
Since the logic needs to integrate with a variety of back-end data stores, 
I am converting all cases of "select blah from widgets where whatever=1" to 
"storage server" calls like "getWidgetInfo(arg1)". The reason for this is 
because there's much more than a requirement for database portability; the 
data stores can have significantly different schemas from site to site. So 
this interface lets me encapsulate all those issues in the storage server 
tier. Since the calls are all XML-RPC that storage server can easily  be 
the same box or something across the country.

One application I see for this in phpGW is the contact manager. If the CM 
code does a call like storageManager.getContactByPhone("416-555-1212"), 
then in theory the storage manager can be configured to pull this 
information from a simple schema, a complex schema, or through something 
more radical like an API call into an ACT! database or Siebel CRM. The 
storage manager can be responsible for transforming the information it 
accesses into a reasonably standardized form for the CM to handle. It's 
true that the CM will still have to deal with different limitations of the 
back end, but at least these branches of logic should remain both somewhat 
limited and easy to understand.

I see other applications to this like making it easier to integrate time 
and expense capture into corporate ERP systems, and more.