> 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
Good point. So, you, or we, the community, will need to figure out the actual requirements for the new architecture in order to make it work with existing (yours and others) extensions so far. I would say: nah - just burn bridges along the way and force extension developers to hop in on the wagon and adjust their code. But then again, we could also provide for a more seamless solution, at both the API level and the DBMS/DDL level. Basically this would mean, keep the old data models and APIs intact, but also introduce the new generic data model and APIs that go along with it. How can this be accomplished during the transition phase? First, the transition phase should be no longer than approx. a year. After that, all of trac's data will be transmogrified to the new generic model, including also its APIs, incl. also the data of the actively maintained extensions. During the transition phase, and at the api level we would then implement facades that would provide the same basic functionality, but under the hood we would map the old data model to the new generic data model during the transition phase. At the dbms level, we would keep the old ddl intact, so that existing extensions would still be able to access the existing data, except for the new data that would then be introduced by the generic data model, for example content relation and so on. So what does this mean in practice? We will - keep all of the currently existing DDL intact - introduce the new tables for the generic trac model and map existing data unto it but do not duplicate, except perhaps for the change history - incrementally re-implement existing code so that it makes use of the new generic data model - introduce facades in exchange for the old apis that will hide away the fact that we actually use both, the old and the new generic data model via the new apis - introduce the new apis which will make use of both the old data model and the new generic one In the long run: - we will move all trac data over to the new generic model - by that time, all extensions should have been rewritten to use the new apis, if not, who cares since those extensions are no longer maintained, which would actually be also a good opportunity to sort out unmaintained projects from t.h.o and dump them to an archive page - existing data from non maintained extensions will be kept intact - users who dearly need the data from the unmaintained extensions will be forced to migrate the extension to the new generic model by themselves or hire others to do it - win-win situation for everyone Dear me, it is getting late (3:25am here), I have some films to watch and I am also getting tired ;) -- will continue on this, and leave you with the above for further discussion. Regards -- Carsten -- 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.
