On 12/12/12 18:56, Reto Bachmann-Gmür wrote:
On Sat, Dec 8, 2012 at 1:03 AM, Claude Warren <[email protected]> wrote:
This got me wondering if the listener implementation in model (and
graph) shouldn't have weak references to the listening entities (e.g.
anything registered as a listener).
I would think so. In clerezza it's implemented like that. see
http://svn.apache.org/viewvc/incubator/clerezza/trunk/rdf.core/src/main/java/org/apache/clerezza/rdf/core/impl/AbstractTripleCollection.java?view=markup
This reminds me that listeners should be part of an RDF common API. Not
sure if delayed notificator are needed at that level though.
Cheers,
Reto
This isn't the only design for events and can be limiting (as has been
found in Jena). For example, it is either sending events before the
real work happens, or after, and it's fixed. The event handler can't
block the operation either.
Using wrappers [1] means that many different event paradigms can be
provided as the application chooses.
Another issue is that only objects that support events can be involved.
You can't send events about a 3rd party object.
A different approach is to separate events from the objects themselves.
A pubsub manager (EventManager) coordinates the registration and
delivery of events. Events are sent on "channnels". "Channels" can be
string names but they can also be java Objects - like the graph the
event is about.
EventManager.sendEvent(graph, event[triple])
This is a volunteer system - the sender and received have to opt-in to
events but it can be applied to any object in the system.
Choosing one style and building it would be wrong for PURR but may be
right for an application API.
Andy
[1] http://en.wikipedia.org/wiki/Adapter_pattern
