John Hampton wrote: > Noah Kantrowitz wrote: > >> This is a bug in Genshi, and I don't want to start talking about >> workarounds until it is clear there is no way to fix it directly. >> > > I have to agree with Noah here. The change should not have any impact > on Trac. That it is highlights the issue with the template engine we > have chosen.
I agree with the "should". Yes, "ideally" the problem should be fixed at the Genshi level. But, precisely because we know that there are problems and we're aiming at getting a 0.11 release, we shouldn't make things harder. Not at this time when everybody start to use the beta releases and expect an official 0.11 release "soon". cmlenz proposed a good fix for the <py:match> problem (http://genshi.edgewall.org/ticket/190#comment:19) but that fix can't be applied /because/ of r6696. Coming up with a similarly good fix that would work even with r6696 will most certainly require a major rewrite of the Genshi match logic - I don't even know what could be that approach, maybe cmlenz has some ideas. But frankly I think it's /very/ unlikely that it could work with similar speed and memory usage, and that it could be available in a reasonable time frame. Alternatively, not using <py:match> and only <xi:include> gives us nearly the same results for memory usage than with the match_unbuffered patch (even slightly better) and in addition, gives us a 20% speed increase, which, in these days where everyone discovers the performance drop compared to Trac 0.10.x, is not something that we can neglect: - 28.2MB and 12.6s for /report/1 with <py:match buffer="false">, - 27.7MB and 9.9s for /report/1 with <xi:include> That conversion is nearly trivial and would need to be done only for the more demanding templates, the others could still use the <py:match> based layout.html (which in turn would now be <xi:include>ing the same smaller snippets - so no template duplication). > The fix should be done in the template engine also. If it > turns out that there is no way around it in the template engine, then I > think we need to think really hard about using Genshi. > Let's not throw out the baby with the bath water ;-) There's more to Genshi than just the <py:match>. I totally agree that using <py:match> is way more powerful and elegant than using <xi:include>, but that's really not the point. Let's try to make Trac usable with what we have now and use <py:match> liberally when/if it gets fixed, not the reverse way round. -- Christian --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
