On Dec 6, 2004, at 11:05 PM, David Christensen wrote:
I'll start by throwing out a rough wish-list that we can all critique and modify:
1. On-line user/support community.
Sourceforge, JIRA issue tracking, mailing lists, usual.
2. Separation of function (code), presentation (templates), and content
(database).
You bet.
3. Genuine Perl; preferably 5.8.
It's pure-perl. I dunno what 5.8-isms are useful.
4. Open-source de-facto standard language(s) and tools for the framework itself and all associated infrastructure used to work on it and the products built with it.
It's all Perl, although the templating engine is Template Toolkit (by default) and configuration is mostly modified-INI files.
5. Perl Artistic License.
Yes.
6. Strong security.
Do you mean the code itself is secure? As far as I know. I think there's only one place where we shell out to do something and that will be gone soon.
7. Documentation -- architecture, design, implementation, test, programmer's guide, designer's guide, author/editor's guide, administrator's manual, etc..
Architecture, design and programmer's guides are pretty solid. Nothing on testing. Not terribly much on gui-type authoring (since we rely on other templating engines for us).
You can see the html-ified docs for the latest release online:
http://www.openinteract.org/docs/oi2/
8. OO design and implementation.
Yes.
9. Ability to sub-class to modify functionality.
Most pieces of the system can be swapped out at deploy-time and run-time.
10. Ability to create and easily add/ remove/ manage/ monitor plug-ins to add functionality.
OI (1.x and 2.x) has distributable application packages. Each package has its own database structures and initial data (and initial security settings) plus code, configuration files and localization messages. And each one is installable/upgradeable/removably by itself.
11. Built-in functionality: user accounts, groups, privilege levels, home pages/ sub-sites, storage management (quotas), search, friendly/short URL's, search engine friendly/compatible.
Users, groups, privileges, search: yes.
Friendly/short URLs: sorta -- most use query strings to indicate parameters, but I think the next beta will have support for:
/MyApp/action/display/1586
instead of:
/MyApp/action/display?object_id=1586
Home pages, quotas: no.
Subsites: no ( I think).
12. Plug-in functionality: threaded forums, issue tracking/ticketing system, CVS client, photo gallery.
Forums: Comes with a basic commenting system (attach comments to any object).
Everything else: it's not PHP Nuke. There's not much of a community to share these because OI tends to be used for internal applications. I know the Dicole folks (http://www.dicole.com/) use OpenInteract2 as a core part of their main product and have a number of community-type features available.
13. Version control and content management system capabilities.
Not built-in.
14. Information architecture hooks.
Not exactly sure what this means. Many interesting parts of the system can throw events and objects can register to listen for those events and react accordingly.
15. Off-line and on-line development/debugging/test environments for coders and designers.
Not yet. You can run OI2 in a 'standalone' environment -- not using a web server at all, submitting requests programmatically -- but it's not used very often yet.
You can use the same application packages and configuration from different environments. So running a standalone LWP server and under mod_perl only requires changes to their respective configuration files (e.g., apache.conf), nothing else.
Debugging support is pretty good because we're using the log4perl package. So it's simple to modify system-wide logging or to confine debugging levels for individual areas.
16. On-line WSIWYG development environment and workflow for authors/editors.
Not built-in.
17. On-line WSIWYG development/debugging environment for novice users to
create simplified/restricted code, presentation, and/or content.
Not built-in.
18. Comprehensive regression test suite for framework and anything distributed/supported with it.
Test suite: yes; comprehensive: not yet. In particular, application packages don't have testing support yet.
19. Ability to run on well-featured shared Linux web hosting accounts.
It does work with a plain CGI interface, but I wouldn't recommend it. Anything with all these features takes some horsepower, otherwise you're building up and tearing down a lot of information with every request.
20. Ability to backup and restore while operational.
Probably. I haven't tried it, but I guess it depends on your database. We can store sessions to the filesystem rather than the database and can do some caching of commonly used objects there (user, groups, etc.).
Good luck!
Chris
-- Chris Winters Creating enterprise-capable snack systems since 1988
