openstack team mailing list archive

[Duncan McGreggor <duncan@xxxxxxxxxxxxx>]

Fwiw, I'm +1 on this :-)

I look forward to reviewing the branch...

d

On 04 Jan 2012 - 14:51, Jay Pipes wrote:
> 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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~openstack
> > More help ?? : https://help.launchpad.net/ListHelp
> >
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp