Akara Project Integration

Akara should be composd of some essential existing components. The major components is composed of the existing 4Suite Server (4SS). This provides the essential document repository features as well as a full featured ACL scheme. Beyond the core functionalities (which are not listed fully here), Akara will pull from existing libraries and WSGI middleware to move out common elements that are not specific to the task of providing a document repository.

Basic Web Application Tools

There are some essential components that are necessary for most all web applications. Currently these features are implemented via custom facilities in 4SS. Some excellent examples are:

Where applicable, the current 4SS features will be integrated into the necessary libraries. The perfect example is HTTP Authentication, where the credentials will be checked against the 4SS ACLs. Generally the method for replacing the non-specific applications will be to consider Paste as it is a comprehensive set of tools that has been thoroughly tested via Pylons.

Bright Content Patterns

Currently the patterns for integration will follow that of Bright Content. The essence is that the environ dictionary will provide an interface points for the different existing 4SS libraries. Where applicable, the 4SS library will be injected into the WSGI application in a similar way the BC store is injected. The assumption is that the libraries can pass their instances to the environ dict in namespaced values for use later.

This does require some considerations as to thread safety, but again, prior work can help to decide the best course. Paste, Pylons and SQLAlchemy all offer tested methods of providing thread safe and scalable solutions to using different libraries within the scope of a multithreaded, WSGI application. With that in mind, the use of existing libraries might help in mitigating current thread safety requirements by using a library that has more testing and/or established practices within WSGI. It is mentioned here to set a standard of analysis in evaluating the existing tools for use with the existing 4SS libraries.

The Store Pattern

In Bright Content there is an Atom store that is used for persistence. It is assumed that 4SS has a similar store facility where the same pattern can be used. To use the store in BC, the WSGI application queries the environ dictionary for the specific store object to use. Here is an example using a store that contains media entries: 

   1 def my_wsgi_app(environ, start_response):
   2     media_store = environ['bc.stores'].get('media')
   3     if not media_store:
   4         res = HTTPInternalServerError()
   5         return res(environ, start_response)
   6     entries = media_store.get_entries(eid=environ['PATH_INFO'])
   7     feed = media_store.assemble_feed(entries)
   8     set_template(environ, 'xslt/media.xslt')
   9     start_response('200 OK', [('Content-Type', 'application/atom+xml')])
  10     return [feed]
  11

There are some essential pieces to consider. The environ dictionary should contain simple dictionary items where possible to reference objects and resources. In the example above, the keys are namespaced, which should be a consistent pattern for both the environ dictionary as well as any child dictionaries. One example of this concept could be seen in a provisioning service. The middleware would place its provisioned application resources in the environ dictionary for other middlewares to use later. Here is a simple example: 

   1 class Provisor(object):
   2 
   3     def __init__(self, next_applicaion):
   4         self.app = next_application
   5         self.services = {
   6             ('http://bc.org/services/schematron', 'schmatron'): 'http://ionrock.org/servics/schematron/',
   7             ('http://bc.org/services/proxy', 'json_proxy'): 'http://ionrock.org/services/json_proxy/',
   8         }
   9                          
  10     def __call__(self, environ, start_response):
  11         environ['bc.provisor.provisions'] = self.services
  12         return next_applicatin(environ, start_response)
  13

Subsequent middleware applications can then use the provisioning service details from the environ dictionary to call the services that have been provisioned. As you can see from the example, the pattern is very simple. In the case of the BC store this pattern places the store instance in the environ dictionary. Likewise, there are other tools available to provide single instances of an object such as the paste config middleware.

Again, this all mentioned in hopes of bringing to light how things are intended to be integrated. This pattern is simply a first attempt at integration.

XSLTemplates

One specific area of integration is XSLTemplates. XSLTemplates takes the response body and checks the environ dictionary for keys suggesting what template should be used. The template is then applied to the response body and returned with the Content-Type specified. XSLTemplates is able to find the stylesheets according to a custom resolver. The resolver allows for paths checked against a template directory and templates in a python module. These resolvers functions both within the stylesheet as well as from the values in the environ dictionary that define the template.

The aim of XSLTemplaes is to provide a template library that can be easily integrated into other WSGI applications and frameworks. Within the scope of Akara then, the goal will be to provide the necessary styling. This may require something of a "render" function that is more explicit, but falls well within the original goals of providing a general WSGI library for using XSLT.

Akara/Integration (last edited 2008-11-24 18:46:30 by localhost)