On 16 apr, 17:56, Olemis Lang <[email protected]> wrote: > 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: > >> 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. Seehttp://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 .
Just to avoid misunderstanding: I don't object to something simple derived from cboos' comment in 11145#comment:2. In my mind this would drop the whole idea of a 'context' and just pass the 'resource'. Resources can be complex enough, but they would still have predictable signatures and content - even with one or more parents or children attached. You can ask for more standard data via resource manager API - making links, titles, description and more. A resource including a 'version' may possibly be requested to provide some details of its change. The IResourceManager methods can naturally be extended if more common ground is needed (and found). Your module publishing the interface would of course have to call out to both to the 'native' listeners, and to the 'resource' listeners. It won't look so neat in code with double work, but that's really no big concern. > >> 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. See, this is just the kind of generalization that will not hold water. We cannot make any assumptions about 'model'. Or some 'changeinfo' data structure or its possible 'oldvalues'. There may not even be a model. Bitten passes a 'build' as only parameter to listeners, but you need to know about how the 'build' consists of a collection of 'steps' with output and errors stored in log files on disk. Are you perhaps suggesting that every 'object' presented through Trac should conform to the same pre-defined data structure? Defining an API by data structure instead of callable methods? > > 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) . I have no problem understanding the problem with imports. Or with mapping all 'listeners' (however we decide to define them). What I fail to understand is how you are supposed in a generic manner to make sense of a 'build' being passed to you (or rather 'context.build' following the code samples)? Would you not need to know that a 'build' is provided by Bitten, and make explicit 'if .. else' conditionals in your code to make sense of the specific data you find? And know where in Bitten to look for more features if needed? How is it better to bury all these domain requirements as implementation details inside a "generic" method - rather than making it explicit and in-your-face with predictable outcomes when problems arise? I just fail to see what non-trivial problems you expect to solve in a generic manner. Or how moving to generic methods would somehow be a better trade-off between features & problems. :::simon https://www.coderesort.com http://trac-hacks.org/wiki/osimons -- 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.
