On Oct 8, 1:10 pm, Christian Boos <[email protected]> wrote: > Take for example the CacheManager
Great example. And a good illustration of the fact that Trac should provide core services for modules to use and reuse. Much in the spirit of how we have provided various other services (and APIs) - request and args parsing, session code, rendering, i18n +++. As developer and plugin author, I can choose other solutions if I really, really wanted to. Or wanted to try out alternative approaches for custom needs. But that usually makes no sense as the core services offered by Trac keeps such high quality. The essence however is that the services are to a large extent 'opt-in' (like the CacheManager), and sometimes there isn't a 'one-size fits all'. The 'opt-in' approach is very different from some future where caching gets built into the 'object framework', and where generic-based objects get caching by inheritance. It is easy to say it will be optional to build on these objects, but we all know that it won't be rational to maintain *both* coding practices over time - supporting two best ways is almost double the effort, and much of the gains will be lost. Over time many standalone opt-in services will become unsupported and fade away. :::simon -- 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.
