On Sep 30, 9:28 pm, Christian Boos <[EMAIL PROTECTED]> wrote: > Noah Kantrowitz wrote: > > Really I don't think we want to move in this direction. The wiki isn't > > supposed to be some generic data storage mechanism. It is just a simple wiki > > with one text blob per page. This kind of generic data storage system just > > doesn't fit with the Trac design philosophy. > > Well, I don't think the above reflects a consensual opinion among Trac > developers. > For example, a few hours ago a core developer of Trac (osimons) sent > another reply expressing his interest for the topic and even shared some > of his own thinking about this (thanks for doing so, btw!). > > In fact, I'd be interested to know who else actually thinks that: > " > > This kind of generic data storage system just > doesn't fit with the Trac design philosophy. > > " > > So far, I only know one other person who has expressed such a feeling > besides nkantrowitz (it was cmlenz). > Quite to the contrary, I remember that other people have expressed > interest or sympathy for this idea in the past (and among the trac core > developers, athomas, ecarter, osimons). Those people are welcomed to > correct me if I got their position on this matter wrong, and of course > the silent majority is invited to speak, as it would be quite unfair > that a vocal person's opinion could be mistaken for the project's one. > > My personal take on the subject is that this should be freely discussed > as a worthwhile design philosophy for Trac, a possible vehicle for code > simplification and rationalization yet at the same time enable much more > flexibility in the system. And if discussions, experiments and code show > that this is a viable and desirable future direction for Trac, so it > should be. >
Just to clearify my point on view on this: I agree that a wiki is a wiki, a ticket system is for bug tracking and so on. I'm no great believer in redoing Trac to be built on a shared object model. The flexibility, possibilities and share-nothing simplicity of the current object model is fine by me. Still, I do believe that one of the great strengths of Trac is the care we have taken through a sensible API of making the components work together by reusing shared APIs for linking, search, timeline and so on. My proposal just builds on what exists today, but adds storage, API and visualisation parts that allows arbitrary resources to be linked and related through plugins. The resource plugin Catalin mentioned above, tags, ticket dependencies and many similar initiatives could all reuse a such a hidden subsystem. "What links here", "See also" and so many other useful features can be implemented in plugins easily on a common model for relationships, and providing any actions through existing (and some remaining) listener and manipulator APIs. I don't belive that needs to change anything with regards to how the current modules work - they need not be aware of the relationships at all as that is just a link between two arbitrary resources of some type as specified by the plugin that manages that type. I personally see this kind of like a shared sidebar in layout.html listing relationships and providing editors by way of plugins along similar lines to how we provide actions in the ticket system. Hope that clarifies my intention with this idea. :::simon https://www.coderesort.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
