On 4/10/13, Olemis Lang <[email protected]> wrote:
[...]
>
> During some time I've noticed some things that have not been included
> in the patch and I'd also like to put under your consideration as well
> . I'll prepare a summary with references to previous discussions we've
> had in [email protected]
>
Firstly @peter even if not explicitly mentioned in the initial message
[1]_ suggesting this feature for Apache™ Bloodhound , the idea behind
`IResourceChangeListener` has been inspired on original
trac:ticket:8834 . The implementation is substantially different
though . In general , in Bloodhound we pay attention to previous Trac
proposals / ideas / tickets / ... especially if features will have an
impact on our copy of Trac core . We'd like to be in synch as much as
possible to make it easy for us to maintain our vendor branch .
Secondly , most of what I mention below is highly influenced by my
personal opinion .
Points that I think should be considered :
1. In order to completely replace Trac core listener interfaces
the interface is missing reparent notifications. As far as
I could see in Trac this is only used for attachments .
* Nonetheless in Apache™ Bloodhound itself (... so also possibly
in other plugins as well e.g. trachacks:SimpleMultiProjectPlugin,
even if implementation details will be a bit different)
reparent notifications will be needed more often .
* With the notion of product environments and resource neighborhoods
installed in place if a resource (e.g. a ticket) is moved
from product P1 to product P2 then two notifications have
to be broadcast (parent = Product X)
a. all listeners in product env P1 will be notified
of the fact that resource was moved somewhere
else
b. all listeners in product env P2 will be notified
of the fact that resource was added from somewhere
else (e.g. migrate and/or update search index data
gathered in P1 context)
* @andrej : this is something we are lacking in our
multi-product plugin and might also have some impact on
plugins like BH Search plugin
2. @christopher: IResourceChangeListener is aimed at unifying
existing I*ChangeListener interfaces so eventually the later
should be phased out .
3. @peter [2]_ if `old_values` is considered to be yet another
instance of event arguments then all methods will have
the same interface
* which makes me wander whether they should be
merged into a single method plus event name
included as argument or another field in event args
object (i.e. `context` in signatures above)
* @peter ... and , by doing so , subsystems would even be
able to define their own event types without
requiring major architectural refactoring . Similar to
actions in trac:comment:1:ticket:8834
4. There are three kinds of clients of this interface
a. Components focused on events for a single realm
(e.g. ticket relationships).
b. Components handling a well-known subset of available
realms e.g. ticket + attachment
c. Components sniffing into activity on every realm e.g.
search indexing , generic notification engines
5. In Apache™ Bloodhound 0.5 [3]_ only `match_resource` is
supported . It behaves like `self._changed_listeners_map[None]`
in the patch
a. That's not efficient O(l * r) , especially considering
(4a) and (4b)
- l : number of classes implementing IResourceListenerChange
- r : number of active resource realms
b. realm subscription might not appropriate for (4c)
since listener would have to be aware of (almost) all
kinds of resource realms .
c. That's the rationale for having the special case of
`self._changed_listeners_map[None]`
6. Proposed patch implies that listener component and resource
listener loops are tightly coupled to model classes since that's
what they'll return in `get_subscribed_resources`
* IMHO that might lead to some trouble
* not appropriate for (4c)
* ... and since the whole resource API relies on abstract
`Resource` concept it'd be nice to use it instead and
rename that method somehow like `get_subscribed_realms`
* ... not all models are associated to realms though
(e.g. ticket versions)
Finally , slightly off-topic , so JFYI :
A. We are discussing now the introduction of yet another extension point
for other kinds of notifications , quite similar to
IResourceChangeListener.
B. Something similar should be done for I*Manipulator interfaces.
{{{
#!sh
$ grep -r class trac | grep -v ".js" | grep Manipulator | more
trac/attachment.py:class IAttachmentManipulator(Interface):
trac/ticket/api.py:class ITicketManipulator(Interface):
trac/wiki/api.py:class IWikiPageManipulator(Interface):
}}}
Maybe there's something else to say along the way , but this is enough
for start .
.. [1] Re: [Apache Bloodhound] #404: Populate default schema on product addition
(http://goo.gl/o4QAK)
.. [2] Re: Transaction resource changing events
(http://goo.gl/0gthX)
.. [3]
http://svn.apache.org/viewvc/bloodhound/branches/0.5/trac/trac/resource.py?view=markup
--
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.
