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. > 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. > 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. 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), 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. And to echo a past discussion, the above can be transposed to data *representation* as well, where producing some intermediate data format can also be a solution for producing rich content in various different end user formats (http://trac.edgewall.org/ticket/6492#comment:34). -- Christian -- 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.
