On 5/2/05, Alan Langford <[EMAIL PROTECTED]> wrote:
> 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.
>
>
yup, we already have that possibility. We call them layers, generally
User Interface (UI), Back Office or Business Object (BO), and Storage
Object (SO) layers. Some apps like EMail juggle these around a little
(SO == imap or pop3 + a database cache).
For instance, the Accounts system can have SQL backend, LDAP backend,
and others could be added into this system. Same with Auth (sql,
LDAP, mail (which pulls the configured imap or pop3), PAM), and I've
got a patch in sysmailadmin (on the forum) to allow a primary and
secondary auth that can be handy for migration between auth systems.
For SO classes, they use the db class which can use many different
database servers, and we've recently replaced an old phplib db
implementation with an ADODB implementation in such a way that no apps
need changed and we can drop in new adodb versions at will and
unchanged.
So, an SO layer can be made for the Contacts backend to get data from
anywhere, and so long as it passes the info back in a way that the BO
layer expects it will all work fine.
The code in phpGW is sometimes overwhelming because it is quite
complex and flexible. It won't do everything you want "out of the
box" but it was written with these things in mind so it won't need any
major design changes to do it :)
_______________________________________________
Phpgroupware-developers mailing list
Phpgroupware-developers@gnu.org
http://lists.gnu.org/mailman/listinfo/phpgroupware-developers
