Noah Kantrowitz wrote: > Christian Boos wrote: > [snip] >>> I guess (correct me if I got you wrong); there shouldn't be a need to >>> write those "adapters" for resources plugins add to the system. >>> Plugins should tell Trac what kind of resource they are providing, >>> and Trac (or yet other plugins) should figure out everything >>> automagically or something. >>> >> The something is mainly a generalized change notification system >> instead of lots of specialized ones, and a bit of metadata about the >> resources. >> >> I don't even have to talk about an eventual Trac cross-reference >> plugin, I can simply take as an example your spamfilter plugin: first, >> it has to provide adapters for IWikiManipulator, ITicketManipulator >> and IAttachmentManipulator, so that it can validate the changes for >> all of them in an uniform way. Even more, if there's a new kind of >> resource added to the system, the spam filter can't handle it, unless >> a new specific adapter is written. As that plugin is not part of the >> core but nevertheless "well-known" as it's on t.e.o, there's some >> chance that a 3rd party contributing a resource will provide an >> adapter for it, but you get the point. >> >> I think this is not the best solution, simply because the differences >> between all those different resources are *very* superficial or even >> artificial - a more uniform data model or at least a more uniform API >> would certainly be possible. > > I've not had time to fully write up my thoughts on this whole issue, but > this needs saying I think. This issue (the generic objects concept) > seems to be the driving force behind much of this design issue. I think > such a concept is nifty, but has no place in Trac.
Well, then we're definitely not on the same "Trac"... What I want to achieve is that all the main Trac resources can share similar capabilities, when it makes senses, of course. So probably no "attachments on attachments", but... - wiki page, changeset, source file commenting - custom fields for wiki pages, milestones, etc. - consistent history and changeset like view over changes made to any resource - consistent change notifications (e.g. RSS feeds or e-mail subscriptions on wiki edits, milestone changes) - automatic cross-references between resources whenever one is referenced as a TracLinks within the wiki content of another resource - queries over any kind of resources (and a substantially improved query language) - etc. All of the above correspond to tickets on t.e.o. Search using the "tracobject" keyword for more. > Sure you can remove > some bits of duplicated code, but the APIs will get more complex and > bigger. Code duplication isn't that big of an issue Code duplication is not such a big issue *now*, as most of the features you have for one kind of "object" are not yet available for the others. Some resources are kind of neglected, like the milestone resource: no preview when editing, no history tracking and notification of changes, no custom tickets, no workflow, and until 0.11, no attachments. All of the above correspond to valid concerns and corresponding enhancement tickets have been created by various users and acknowledge by me (e.g. #3776, #3068, #3003, #1673, #1113). How would you implement those without duplicating the code, if not by introducing some kind of generalization, be it at the data model level or at an API level? Now, think about creating new kinds of resources, like component, repository, project, users, as "first-class" resources in Trac. All of the above apply again. > to me when it is in > such a way that things are not _likely_ to break. I think this > higher-level design issue needs to be agreed on before this progresses > much further. Yes, I think we definitely need a vote here, for clarifying the future directions. I do believe that the idea exposed above is what would make Trac truly unique and powerful. Let me quote what I wrote three years ago in the TracObjectModelProposal: The tight and coherent integration of its (Trac) features is achieved by several means, but most notably by the consistent use of a unified language to talk about objects in the system (the TracLinks). This unique approach enables a powerful structuring of the information in the system, yet this can be achieved in a very flexible and informal way. In this light, Trac is a semi-structured Wiki, where one can create and modify objects and talk about them. This is still the vision I stand behind, and I'm not really interested into working and putting my time into something else (what else by the way, yet another web framework?). So if there is a disagreement over that direction, then I suspect we need a fork. Which would be the "right" approach should probably be left to the users, as from my experience, the ideas exposed above do quite adequately match lots of the expectations expressed by the users, both on the mailing lists and in tickets on trac.edgewall.org. See also http://trac.edgewall.org/wiki/GenericTrac for a more recent proposal about the direction I'd like to take as soon as 0.12 (note that this proposal encompass multi-project support as well). I haven't yet heard or read about any alternative ways for implementing the shared capabilities on Trac resources. Until you expressed the following view: > I really don't think we should pursue any kind of layer > that is that generic, its just not going to help in trying to > re-minimalize Trac. What does that mean? That you don't /want/ to see those shared capabilities I listed at the beginning of this mail? Let's take a concrete example, does that mean that you're against implementing any of the milestone improvement listed in #3776, #3068, #3003, #1673, #1113? (too late for #3068 though...) If yes, why? If not, what would be your way to do it? -- 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 -~----------~----~----~----~------~----~------~--~---
