I see two different, complementary paths for integration, first internal integration and second external:
[E]mphasizing integration still makes sense to me, so how to do it? When I started writing OpenACS documentation in 2002, the old docs recommended making new records in your new app "ACS Objects," but the only tangible benefits to an extra 200 lines of nasty pg/sql were permissions and general comments. Now you can make your records cr_items (actually you could do that all along) in < 10 lines of code and the list of benefits is: permissions, version control, mime typing, comments, notifications, workflow, categories, and rss (?). The key is urging everyone to use acs_objects/cr_items as their basic building blocks, and to write features based around acs_objects.
For external integration, the idea is that an OpenACS site is a neutral "meeting place" for different web services data. If we can get basic feeds of external data into OpenACS, we can treat them as local objects and - whammo - get all the OpenACS features.
Example: You have customers with data on one system, and you want to use that data on a second system, and you also want email notifications when the customers do stuff, and you want to categorize your users and have the same categories be in sync on both systems. In order to get the two systems to talk at all, you will have to get each to input and output lists of records. Instead of reconciling the lists in one or the other of the systems, you use tools in OpenACS to reconcile the lists. When you add a third system, maybe LDAP authentication for your users, you just link it in to OpenACS and it's trivially linked to the other systems.
The technologies we need to be a good central integration server are simply importing and exporting data and synchronizing data. We've done each of these in isolation, with acs-authentication (batch import and sync of user lists), authentication service, two-way syncing (new feature in acs-lang 5.0.0), RSS feeds. The next steps to compete here are: generalize the solutions in these packages into core tools, start talking more standards (IMS, etc), and start using one or more methods of globally unique naming (guids, unique names via email addresses/server names, etc)
