Open Stack

No argument from me. Feel free to propose a branch that does the
things you describe below. I'm sure you'll get feedback in code review
:)

Cheers!
-jay

On Tue, Jan 3, 2012 at 2:17 PM, Joshua Harlow <harlowja at yahoo-inc.com> wrote:
> I was wondering if there has been any thought or consideration of removing
> tempita and replacing it with “just python”.
> Personally the current tempita usage (libvirt.xml.template) seems to be
> heading down a hairy path and I wanted to see others opinions on say
> replacing this with something that doesn’t require a whole templating
> language to use. Some of this may just be my bias against templating
> languages from experience in different projects @ yahoo (they always start
> to get hairy, especially when u start to code in them).
>
> Some thoughts:
>
> Assuming we can get a libvirt.domain.xsd (?) we can use a xsd->object model
> utility to transform that xsd into a python object model (there seem to be a
> couple of these?)
>
> http://www.rexx.com/~dkuhlman/generateDS.html or http://pyxsd.org/ (or
> something else?)
>
> Create a exposed “tree” representation of the sections of the libvirt domain
> xml that we are interested in (and only those that we are interested in) as
> python objects and have current code create these objects (which right now
> is basically a set of python hashes getting sent to the tempita library)
> Pass the root element of this exposed “tree” representation to a formatter
> class (which itself could use pyxsd objects, or tempita – for backward
> compatibility, or something else, but I have a strong preference for keeping
> a single language in use, instead of a tempita language and a python
> language).
> Write output created by formatter class to domain.xml file (and continue as
> normal).
> Profit!
>
>
> Some of the benefits I think exist with this:
>
> XML escaping will actually happen (does this happen right now?)
> We can have a underlying object layer which comes directly from the
> libvirt.domain.xsd (and possibly have versions of this to work with
> different libvirt versions)
> We can have an exposed object layer which will attempt to be version
> independent of the underlying layer and only contain methods/properties that
> we will use with libvirt (ie the xsd will have many properties/fields we
> will not use, thus we should not expose them).
> We can have a formatter layer that will know how to use this exposed layer
> and return a object that can convert the exposed layer into a string, thus
> allowing for different implementations (or at least a separation of what is
> exposed, how its formatted and what the formatter internally uses).
> We can have the if statements and loops and such that are starting to get
> put in the template code in python code (thus u don’t have to context switch
> into a templating language to make changes, thus making it easier to work
> with libvirt).
> Possible remove a dependency (always good).
>
>
> Thoughts?
>
> -Josh
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>