Centralized Interface Manager

There may be some lessons from ODBC outside of database issues.

I tried to get SqLite to work with 2 different version of PHP on two different machines and still haven't succeeded after long nights with php.ini re-editing and downloading and moving different versions of DLL's up, down, and all around. Perhaps some of the problem is with the Windows OS, but either way, it sometimes makes pre-packaged boxes of vendor software look inviting. Sometimes it appears that the OSS software coders coded for performance instead of ease of installation and integration.

I think OSS needs something like ODBC (but not just for DB's) where a service is registered and listable. Different products only have to be able to be registered as a service to communicate. This reduces the need to make connectors for say 10 different databases to 10 different languages, with 10 different versions each, etc. OSS seems to have a combinatorial explosion of component combinations.

The same may apply to GUI drivers, geography mapping engines, network interfaces, etc. In many ways things like HTTP, FTP, etc. have already done this, but they are designed mostly for networks. There seems to be a lack of similar things for intra-server connectivity. Even a general connectivity standard such that DLL's etc. aren't necessary would be helpful. Thus, if one does not exist for a given specific domain or tool, one can use the general inter-process messaging protocol. Think of it as non-binary, cross-platform DLL's.

Note that ODBC is usually slower than native interfaces, but often it beats native interfaces that don't exist or don't work.

Services that are registered and listable? Applicable to GUI drivers, geography mapping engines, etc.? Non-binary and cross-platform? Works equally well locally or over a network? I believe you want WebServices.

For local stuff? WebServices tend to be too bulky and slow for that. However, in a few years we can perhaps throw hardware at the problem. Also, configuring HTTP interaction can be a pain for local machine use, perhaps an AbstractionInversion of sorts.

CategoryInterface, CategoryComponents