On 18 apr, 15:18, Andrej Golcov <[email protected]> wrote: > I've just added an alternative proposal as comment on the > ticket:http://trac.edgewall.org/ticket/11148#comment:5 > > Please share what do you think on this. > > Cheers, Andrej
I've added a brief comment, and as far as I can see this works exactly like Listeners do today? Anyway, let's take a step back first: I'm not saying the current *Listener interfaces are perfect. Far from it. The main problem in my mind is that they are already way to limited due to the limited data they get passed. Like no request context, no user, no permissions. The things you can do in and around Trac without user and permission information is very, very limited. Really restricted to just doing 'bookkeeping' in plugins that create related data structures behind the scenes - like how deleting a ticket could also delete tags pointing to it, for instance. The need for 'generic' notification and similar user-facing needs has been mentioned many times in this thread, but that seems to not quite see the whole picture as without user and permission you cannot notify. If you change a ticket that is marked as 'private' through some security policy, no listener (generic or otherwise) have the required information to enforce security before passing the information along to users. What you can safely do with generic notifications is very limited. This is main reason why our notification system (trac.notification) for the large part have retained its pre-0.9 implementation. Not much in the way of API-based thinking in the deep corners of that sub- system... The lack of better internal notification/listener interfaces is the number one reason why. It really should have been completely redone to only use *Listener interfaces instead of the direct call architecture we still use. To further add to the perspective I'd also like to mention our *Manipulators as their issues are somewhat related - and yet completely different. These are usually much more 'powerful' interfaces that allows us to do much more - we usually have a request with perm, user and all we need. The problem then is that it actually becomes hard to use when not accessed through the web interface. Which is why for instance the ticket-commit-updater component that gets called from repository hooks (via 'trac-admin changeset added') can't call manipulators, and only calls out to listeners inside ticket save_changes() as that don't depend on a 'req'. This can all be found in http://trac.edgewall.org/ticket/10125 for those interested. Complex non-obvious objects with unbounded storage options should not be passed as part of APIs. Even 'req' fails this test because we cannot faithfully recreate all parts and variations outside a request context. So let's instead gather the bits we all should depend on and that would be the minimum set needed to do useful work in all contexts. perm, user, resource and href is a good start, and pass each as named arguments and set to None if unavailable. In a pinch I would settle for using a well-defined OfflineRequest with essential data and passed as 'req'. I appreciate the effort taken to discuss our Listener architecture (and by extension Manipulators), but personally I would like them to be able to do MORE instead of LESS. That's where I think we should be spending the effort, and this is the perspective we should have when trying to come up with better ways of doing it. Please let us continue this discussion! :::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.
