Thanks osimons and cboos for your replies . On 4/16/13, Christian Boos <[email protected]> wrote: > On 4/15/2013 12:09 PM, osimons wrote: >> [...] The commonly used >> 'fix' to improve documentation for generic calling is of course to >> have 'context' refer to some sort of data structure description and >> version. Like perhaps providing a versioned schema to describe the >> data passed? This 'XML way' is really not how I would like us to do >> thing in Trac... > > I think that something like this is indeed necessary to make the > `IResourceChangeNotificationListener` really useful. Describing the > model fields in a way close to what we *already* do in > `TicketSystem.get_ticket_fields` should be enough. >
Well , osimons message enlightened me to actually think of another way to get this done . I'll try to work on a patch towards this alternate implementation and upload as soon as I could get it done . >> Regardless of perceived ease of code sharing, you should not be >> listening to events that you aren't prepared to handle. You need >> domain knowledge to know what you get and what to do with the data. >> And to do more useful work you may even need to be able to use the >> data to initiate actual model objects or call domain-specific API >> methods. It all requires know-how that cannot and should not be >> abstracted and generalized. There can be no meaningful sharing across >> unrelated domains - at least nothing that can compensate for managing >> and developing against this new complexity. I see no great benefit of >> rewriting all implementations to do 'if .. elif .. else' to first >> check for resource realms, and then calling out to internal helpers to >> _do_wiki_update_event() for decoding of hidden data and handling of >> the event. > > You don't necessarily need to oppose the two ways. > They also can be seen > as complementary. See http://trac.edgewall.org/ticket/11148#comment:2 > which precisely address your concerns above. > We can keep the existing interfaces (or something close), plus reuse the > proposed dispatching machinery (`ResourceManager.notify`) for > specialized events. And at the same time have the "generic" events (the > tip of the iceberg) made available for the generic listeners. > I agree . >> The generic API may look simpler and cleaner, but there is nothing >> simpler about the actual work and know-how involved in using it. Some >> things stay the same, some things will just require doing things in a >> different way. To return to the original post in this thread, how >> would a search engine listening to events be expected to make sense of >> the blog, build and chat data it receives in order to update its >> index? > > Because those plugins will present a minimal description of what can be > found in the corresponding "model" element. We can also expect to have a > model.resource property for the identity of the object. The "changeinfo" > will be standardized (e.g. author, timestamp, reason) and "oldvalues" is > the backup data for the modified fields in "model". With that, you'll be > able to index the content of your objects in a generic search system. > I think I should mention that Bloodhound Search plugin implements extension points for custom indexing strategies . This would be useful to have a default indexing strategy and fall back to it if no indexing enhancements are found <= @andrej cmiiw Besides this I was thinking of other use cases as well that could be benefited by the introduction of IResourceChangeListener interface in a generic way . For instance let's think of a component implementing XMPP or other kinds of notifications of anything that's taking place in an environment .Considering the preconditions mentioned above by cboos . Provided that there is consistent MIME types for models (e.g. 'x-trac-<resource realm>') then by using `resource` it would be possible to look for available conversions from 'x-trac-<resource realm>' onto 'application/atom+xml' (i.e. Atom <entry />) wrap it inside XMPP pubsub envelop (i.e. XEP-0060) and notify interested parties . > The overall problem we're trying to address here is the following. > If you want to propose a service that tries to address a cross-component > concern (typically the timeline, the search), ... notification engines ... > for now it better has to > be an interface (`ITimelineEventProvider`, `ISearchSource`) coming from > trac core, which have the privileged position of being "well-known" > interfaces, otherwise if you're just a plugin among others, you can be > sure that only at best a small fraction of the other plugins will be > interested in implementing that interface. Or you could implement the > glue yourself, again for a limited fraction of the existing plugins. > Either way, you can't expect to have more than partial "coverage" in > this N x N situation. Or you make it possible to have a middle ground (N > -> m -> N), N plugins producing data for a restricted set of m > well-known generic interfaces, which in turn can be consumed by N > plugins. Again, I don't say that *all* interfaces have to follow this > model, but that having this is a nice addition to the system, opening > new possibilities. > The way I see it using interfaces also means that there are import dependencies to anything that could be notified . Therefore , a generic notifications solution (like the one mentioned above) would have to : a. Know of all imaginable resource-specific listener interfaces b. Import each one of them c. Subscribe itself (somehow) to resource-specific notifications d. Keep track of all other new I*ChangeListener interfaces implemented by plugins installed at run time . Option (d) is the tough one In my previous messages I mentioned that clients of IResourceChangeListener interface would may be classified in one of the following groups: 1. components subscribing to notifications in a single realm e.g. I*ChangeListener as we know them today . 2. components subscribing to notifications in a well-known set of realms e.g. `ticket` + `attachment` 3. components interested in all sorts of notifications no matter what realm it is about . Grups (1) and (2) would be ok with the realm-specific interface approach , but there's no hope for components in group (3) . [...] Summirizing : I'll be working on a new patch for you to review based on osimons comments . -- Regards, Olemis. Apache™ Bloodhound contributor http://issues.apache.org/bloodhound Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/trac-dev?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
