Forum OpenACS Development: Re: FYI: My Vision and priorities for OpenACS
Emphasizing OpenACS's strength in integration makes sense. That concept and core strength has been there all along in some way or other starting at least as far back as Philip's "the important thing is the integrated data model" spiel. I do sort of worry though about too much emphasis being placed on "integration" and losing OpenACS's other historical emphasis on rapid development, fast turn-around, and a toolkit that just plain gets out of your way when you need it to.
These two "integration" and "rapid development toolkit" goals are not contradictory, in fact they can and should be mutually supporting, but there is tension between them. It's easy to imagine and fear so-called "integration" getting exclusive control and wandering off into the same wasteland that swallowed ACS/Java.
Anyway, on balance emphasizing integration still makes sense to me, so how to do it? Increasing the use of various existing tools (Workflow, List Builder, etc.), the dotLRN/OpenACS refactoring and integration work, and other existing efforts (rpm/deb installs, etc.) should all obviously help there.
But past those, in practice, further integration improvements are going to have to mean adding much more powerful tools to let OpenACS package authors more simply and powerfully achieve integration, consistent behavior across packages, etc. (Or so it seems to me. Any contrary opinions?) And I think that's going to be the case regardless of whether OpenACS receives a huge influx of new users and developers or not.
With current resource levels, new tools will be needed to leverage the same developers' time into faster improvement. With lots more developers, probably much the same new tools would be needed to help channel all that extra effort into the most useful paths, rather than diverging off into all sorts of contrary directions that end up hurting integration.
This data-centric "data soup" direction seems to be major new integration idea so far. But, I don't really understand what that means yet. Are there any concrete examples of that sort of thing around yet?
Hm, also, I'm not sure why Ecommerce is considered a non-strength of OpenACS. I thought that historically, quite a few ecommerce systems had been built with OpenACS, and Ecommerce functionality often blends fairly naturally into other groupware/community aspects of a site. But I never had any personal experience doing Ecommerce stuff at all, so are my assumptions here misplaced?
[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)