Thanks everybody for the useful response. May be I have to share more details regarding my question. In scope of Bloodhound project we are preparing prototype implementation of full text search (you can find more info on [1]) with respect of Trac Advanced Search proposal [2], search refactoring [3] and AdvancedSearchPlugin[4]. Currently, whoosh framework is used as a free-text-search backend.
The idea is indexing a resource (e.g. ticket) in a free-text-search backend (Whoosh or Lucene/Solr) after it was added/changed into DB. ITicketChangeListener looks like the most appropriate existing interface for this purpose. I don't think that ITicketManipulator, IRequestFilter or IRequestHandler are appropriate. I wanted to use a request object to call add_warning in case of possible indexing errors, of cause, if the call is in web context. Based on your feedback, I will rethink the design to use something similar to AnnouncerPlugin for errors notification. BTW, ITicketChangeListener does not provide all events required to support external index consistency. But I would open another thread on this subject. > As the description tells, it's an > "Extension point interface for components that require notification > when tickets are created, modified, or deleted." > > Components, no word about sessions, and if you compare it to other > interface definitions you'll see, that the missing request is on > purpose. This interface was not meant to work in an interaction context, > but to enforce side-effects of ticket changes on other Components. > That's it. I would not agree that component that subscribed on ticket changed event doesn't need to know in what context the call is happen (context can be a web request, trac-admin call or whatever). I believe there are a lot of cases for this, like WorkflowNotificationPlugin mentioned by Ethan. I agree that context should not be passed as parameter but, IMHO, some ortogonal context facility will be useful, may be something like "env.current_context()" function. [1] https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0004 [2] http://trac.edgewall.org/wiki/AdvancedSearch [3] http://trac.edgewall.org/wiki/SearchRefactoring [4 http://trac-hacks.org/wiki/TracAdvancedSearchPlugin Regards, Andrej -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To view this discussion on the web visit https://groups.google.com/d/msg/trac-dev/-/YbEvud7tKH4J. To post to this group, send email to trac-dev@googlegroups.com. To unsubscribe from this group, send email to trac-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
