Update
To more easily understand - this is how MRL currently does subscribptions
A possible enhancement would allow references or static values to be mapped into the subscription / publication route.
Like this :
I think part of the goal is to easily create subscription / publication message routes which get evaluated like lambda calculus. Such languages as Lisp and Scheme turn their own execution flow into a data structure that the program itself can change. This is one of the reason these languages are often used to implement types of Artificial Inteligence.
Heh - looks like Java (lambda expressions in JDK 8) is starting to catch up :)
An idea I thought about .. right now MRL can only do single parameter method subscriptions, this would allow multiple paramters. Think about it as .. MRL currently only has straight pipes connecting things together.. if this was added, MRL could use Y shaped pipes. You can build very different things then.
Service's subscribe method - the purpose is to subscribe to methods like events and use the returned data as
input to another method.
Service.subscribe(String outMethod, String publisherName, String inMethod, Class<?>... parameterType)
currently parameterTypes are not utilized, but the intention was to subscribe to a specific outMethod, using parameterTypes if
necessary to distinguish differet outMethods with the same name e.g. test(String) test(String,String) etc..
You may not subscribe an inMethod to an outMethod if the outMethods return type does not match the inMethods input paramter type.
e.g. if take no parameters in() and the outMethod returns String out() - then you can not subscribe String out() to in().... if in took an String
parameter you could e.g. in(String) can subscribe to String out()
Some small up casting exists with the primitives such that you can subscribe in(int) to Integer out() but it incurrs a little overhead
Now what if you could make subscriptions to individual parameters such that in(String, Float) could subscribe to String out1() AND
Float out2() - concievably - each would be operating on a seperate thread - and blocking or timeout would need to occur when the String
data had arrived, but the Float had not or vis versa
