Why a reluctant coder chooses OpenACS though missing generic features
This post is a continuation of a series on critical reviews by coders of OpenACS. And, what it means as a reluctant coder.
Review: There’s a lack of ways to extend fields from the UI.
Extend any table or object by using any of these techniques:
- by creating another table and using the same reference key
- by using custom fields as part of an application’s feature set (XoWiki and ecommerce for example)
- by creating an object (with new object type) in the object system
- by using the content repository system, an extension of the object system
As a reluctant coder, having pre-built apps with extended fields seems very important. And yet, many OpenACS apps don’t have extended fields. Apps with a specific purpose can be slower when introducing extended fields. Use them with caution. Field extensions can get in the way of a streamlined implementation. Some users avoid apps with unnecessary complexity.
When customizing a pre-built app, keep your changes in separate files from the original when possible. The separation saves having to resolve code conflicts later, when upgrading the original app’s code to a new version. There are a variety of strategies to do this. One bullet-proof way is to place customized code into a new package. And use customized package as home to the app.
Review: little web-based logging and monitoring functionality, something lacking in most commercial platforms
NaviServer has extensive logging built-in. See nsstats. When installing OpenACS with gustafn/install-ns scripts, the script places nsstats at: /admin/nsstats. From this page, view logs and change recording level of notices: Bug, Debug, Debug for connection channel, Debug for ns:driver, Debug for request, Debug for sql, Debug for task, Dev, Error, Fatal, Notice, and Warning. External monitoring is compatible with Munin ( munin-monitoring.org ). Here is an example Munin report of openacs.org: http://openacs.org/forums/message-view?message_id=4074774.
Review: Inter-framework compatibility lacking. Where are generic plug-in web services such as XML/RSS/SOAP/WDSL/JSON?
OpenACS offers a variety ways to do web service paradigms. Some are part of existing apps without the need for a plug-in or the plug-in paradigm, such as with XoWiki, and payment-gateway for ecommerce. Activate them by configuring a few parameters that switch the service on. The plug-in paradigm is unnecessary.
OpenACS also has a variety of parts for creating a specific solution to a custom implementation. OpenACS’ core API includes tools for implementing custom web services: JSON, XML etc. You might need to test a few to see which one will work best for your situation. OpenACS’ api and NaviServer/Tcl libraries fit most any web service with minimal effort. If a service is available in another language, one can use NaviServer’s nsCGI module to integrate it.
As a reluctant coder, know that many web services are built-in and that tools are available to help you create your own bespoke web services. Many web services are fads put forth for others’ marketing purposes. This makes providing honest, generic, monolithic web services a moving target. For example, see Reactivating oacs-dav with file-storage. An in-use web service tends to be a custom subset of a web service’s full potential. You want tools for making it easy to adapt a custom web service in a changing environment.
A goal of web services is scalable interoperability. Use existing stack’s features to not increase breadth of knowledge needed to support services. Publish descriptions of services so that communicating between human agents is unnecessary.