openstack team mailing list archive

["Kevin L. Mitchell" <kevin.mitchell@xxxxxxxxxxxxx>]

Just writing to let everyone know that there has been a minor change in
api-paste.ini introduced by my recent XML templates merge-prop.  The
line in question is the pipeline for [pipeline:openstackapi11]: the
addition of the serialize middleware just before the extensions
middleware.  Below you will find a [filter:serialize] section that
should also be added, but I would also like to point out that Brian
Waldon's recent change, which nuked the Openstack v1.0 API, also
completely removed the [pipeline:openstackapi10] section.

        [filter:serialize]
        paste.filter_factory = nova.api.openstack.wsgi:LazySerializationMiddleware.factory

I'll finish this email with a brief description of the import of the
change.  The tl;dr summary is: It is now possible to write request
extensions without having to deserialize and then reserialize the
response body.

The longer version: The XML templates code replaces most of our current
XML serializations with an XML template system; instead of hand-coding
conversion to XML, which is what we were doing before, you construct a
template (in a fashion similar to how you constructed the XML directly;
templates are deliberately designed to have a similar interface).  That
template is then passed an object, which it serializes into an XML tree.

The key innovation is the ability to create slave templates.  A slave
template has just the basic tree information, plus any additional
attributes or elements necessary to serialize data that the original
master template did not know about.  The slave template can then be
attached to the master template, and when the master template is
rendered, the patches proposed by the slave template will also be
rendered.

Another important point is that serialization can now be done lazily,
which is the purpose of the serialization middleware; when installed, it
sets a WSGI environment variable that causes the serializer (and
associated template, if any) to be inserted into the environment.

These two innovations together make request extensions possible; up
until now, if someone wanted to build an extension that modified a
request, one would have to discern the type of the data, deserialize it,
add the additional data, then reserialize it, probably with another
hand-coded XML serializer, if the requested representation type was XML.
Now, the request extension handlers are passed the object (rather than
having to pull it out of response.body) and can modify it, and/or attach
slave templates to the template in the "nova.template" WSGI environment
variable.
-- 
Kevin L. Mitchell <kevin.mitchell@xxxxxxxxxxxxx>

This email may include confidential information. If you received it in error, please delete it.