Proposal for changes in InformationBroker plugin

[GoogleCodeExporter]

Hello

In its current state InformationBroker plugin is mostly for demo reasons,
but there's easy way to make it more real-life (and business) oriented.

I propose following changes:

- subscribe() method shouldn't call checkSubscriptions(), because
subscriber should receive notifications sent only _after_ moment it was
subscribed. Currently subscriber fires even if information was set/update
before subscription.

- checkSubscriptions() works incorrect with ALL_SET subscription mode
a) if nothing changed then no subscribers should ne notified.
b) subscriber should be notified only if item it subscribed for is changed.
Currently - after the moment all items match - subscriber notified every
time any item changes, even items not in subscription.

- sometimes items should be "consumed" (set to null) silently without
firing notification events. As you provided no method for this I propose
consume() method

I attach modified InformationBrokerImpl.java file. It's not optimized but
works.

Any ideas?
McSeemZ

Original issue reported on code.google.com by McSe...@gmail.com on 15 May 2010 at 10:17

Attachments:

• InformationBrokerImpl.java

[GoogleCodeExporter]

Thanks for your suggestions. You are perfectly right, the InformationBroker 
right now is only for demo 
purposes, and for me to have a look if it's useful or not (and to see how a 
good and balanced IB interface 
should look like).

The idea of IB is to have a common place to register values, query them and 
listen for changes to these values.

The reason why subscribe fires even very early is that you can just subscribe 
to one channel and you get 
notified even of the initial value, the current behavior is intentional, but an 
option could be added not to get 
the initial result. 

ALL_SET might very likely be wrong, but I haven't verified that yet. However, I 
even thought about dumping 
the conditions completely and focussing only on single keys. 

Any suggestions about that?

Original comment by 200712@xeoh.net on 27 May 2010 at 3:20

• Changed state: Accepted

[GoogleCodeExporter]

Hi,
If your real-life project should be notified of already set items then an 
option is a
good solution. It's your code, at least :)

As of dumping multiple keys conditions, then it's natural to drop them in IB as 
such
logic can be moved inside those plugins that require complex behavior.

Also, I suppose your code fires listeners in separate thread, right? Probably, 
this
should be optioned too, as I met some cases when an item is quite complex (e.g. 
GUI
window), and it changes in parallel with plugin receiving and processing such
notification.

Hope this was useful for you.

Original comment by McSe...@gmail.com on 27 May 2010 at 3:55

[GoogleCodeExporter]

InformationBroker has been completely revamped. The interface differs, it also 
replaces the Bus, and has a convenience InformationBrokerUtils helper class.

Original comment by r.biedert on 28 Sep 2010 at 1:18

• Changed state: Fixed