[swordfish-dev] Chat transcript 24/11/2008

[Oliver Wolf <oliver.wolf@xxxxxxxxx>]

Title: Chat transcript 24/11/2008

[START Transcript 24/11/2008]

Andrey Kopachevsky
Hi, guys I have 2 topic to discuss:
1. Filtering swordfish events, we have too proposal how to implement it, first issue that I've implemented and commited is SeverityAware interface with getSeverity() method, use of this technique assuming only severity-type filtering, so other proposal is to add generic EventFilter interface to event api. So user be able to implement custom filter strategy.
2. We decided with Volodimyr that using org.eclipse.swordfish.compatibility.smx3 with amount of inner 3dparty jars is quite ugly solution and better way is to figure out what jars we really use and finde ready to use bundles for each ot them. So, I can start working with this.
Other topic is refactoring our core bundle and dividing it on several more specialized bundles..

Oliver Wolf
@andrey: regarding 1), i would go for the generic option
regarding 2) yes, that makes a lot of sense

Andrey Kopachevsky
ok
BTW do you know where we can see video from eclipse conf?

Dietmar Wolz
Hi, regarding 2), did Volodymyr not already some research in this direction?

Andrey Kopachevsky
yes, but in general perspective, it is not cleare how much time and work would it take
I'm now proceeding with events part, after that I'll take a look on second problem, probably I'll need Guallaume advice

Dietmar Wolz
so you could invest some hours and we decide then whether we will proceed

Andrey Kopachevsky
yes, I'll start tomorrow with that
it will be easier as long we have integration tests

Dietmar Wolz
I will do the refactoring, I propose to put the configuration and event handling in separate bundles, please tell me when you have checked in your event related changes

Andrey Kopachevsky
ok
about events filter, what would you say if I will not create new interface for event filter, rather add appropriate method to EventHandler interface?
public interface EventHandler<T extends Event> {
    String getSubscribedTopic();
    void handleEvent(T event);

    boolean filter(T event);
}
or better name boolean accept(T event);

Oliver Wolf
problem with this approach is IMHO that the system tries to deliver every event and then the handler rejects it. this will probably create more laod then filtering directly on the subscription

Andrey Kopachevsky
I see

Dietmar Wolz
there are special properties used for handler registration which can be used to filter before the events are "delivered" to the handler. These properties are EventConstants.EVENT_TOPIC and EventConstants.EVENT_FILTER. Values for this properties could be derived from an EventFilter
Andrey Kopachevsky

Andrey Kopachevsky
@Dietrmar why do we need separate EventFilter class in this case?

Dietmar Wolz
It could be a kind of "hook" for providing the detailed mapping to filter expressions used as EventConstants.EVENT_FILTER values. There could be for instance special EventFilter objects mapping severity values to EVENT_FILTER expressions

Andrey Kopachevsky
ok, it make sence

[END]

Want to join the chat? 
http://www.skype.com/go/joinpublicchat?skypename=ranyart99&topic=Swordfish%20Developers&blob=Gu7tZh64gTuo551Icz6_iwhXVeXxQ0K4yEzI5XFwGdWIQ_-miteLtgSBILodJ8koN6Uwy9PiotEU5ewRYFqEJeUtl1Yhfc1ipuVwOFz0SWN9HwMZAeikprh0R_8


-- 

Oliver Wolf
SOPERA GmbH