On 08.04.2010, at 09:23, Eirik Schwenke wrote: > W. Martin Borgert skrev 07. april 2010 23:23: >> On 2010-04-07 17:02, Christian Boos wrote: >>> But if it's still not released in a month or so from now, then we >>> could indeed integrate the genshi/ files as tracdep/genshi.* and >>> make sure that the Trac plugins importing the genshi modules will >>> actually find our tracdep.genshi ones (hopefully a >>> `sys.modules['genshi'] = tracdep.genshi` will be enough). >> I think, this model is not an option for Debian nor for most >> other Linux distributions. Debian, and surely others as well, >> work very hard on removing embedded code copies. Adding a new >> copy would be a stop in the wrong direction. Embedded code >> copies make QA work, especially security fixes, very hard. Also, >> they bloat the archive. They constitute a policy violation in >> Debian. It would be preferable to find an alternative solution. > > Warning: it might be a bit to early in the day for me to be posting this -- > if anything below looks confrontational that's *not* intended... > > > I'm a bit confused -- why wouldn't we just slap a 0.6 on genshi, and place it > under the trac umbrella ?
Genshi pretty much *is* under the Trac umbrella, and releasing trunk as 0.6 is the plan. [snip] > Anyway, I think there are three seperate issues, that all warrant discussion: > > a) Is the speed of genshi doomed due to genshis design? And if so, > should we for *speed reasons* give up on genshi ? The current design is inefficient in a number of ways. The whole design choice that everything is streamed through the pipeline event by event (SAX-style) using Python generators has proved to be rather poor. That match templates are processed at render time makes their use quite expensive, and it certainly doesn't scale to a larger number of match templates. It would be possible to move Genshi towards a more efficient implementation by: * Dropping support for dynamic XInclude tags, i.e. Genshi would need to know what gets included at parse time. * Moving match template processing to the parsing stage (aka static match templates); or alternatively, drop the match template idea altogether and move to the more conventional model of template inheritance where the master predefines slots that can be filled. * Compiling templates to Python bytecode. * Providing a fragment caching system. * Etc. It would still not be in the same league as highly optimized text template engine such as Mako or Jinja2, but I think it would be totally usable. As a point of reference, Genshi trunk is in some cases actually faster than Django templates in raw throughput when you don't use things like match templates (last time I tested at least), and lots of sites use Django templates. I think that doing the above changes would make Genshi consistently faster than Django templates (at least the current implementation). But those changes also require a lot of work, and would obviously take away some features people (including Trac and Trac plugins) may have been relying on. It'd basically be Genshi2 ;) > c) Does genshi's stream-filters provide enough of an advandage > to push for b) over a) ? Not sure. Stream filtering is used for a couple things, most importantly form filling and localization. Removing stream filtering leaves two alternative ways to achieve these (and similar) tasks: * post-process the generated output (parse/transform) * take care of everything right in the template, i.e. manually fill in form values, gettext() all strings, etc. Stream filters are nice in that they let you implement "cross-cutting concerns" outside of the templates, and doesn't require a post-processing stage. Whether that's worth the cost I don't know. Cheers, -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
