Ack, forgot to hit "Send" on this quite a while ago. 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. 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 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. 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.
--Noah
signature.asc
Description: OpenPGP digital signature
