Server OnResponse interface

[GoogleCodeExporter]

We need to implement an "OnResponse" interface on the top of the server, and 
also for the JSE client (especially for the rpc plugin).
(exactly the same functionnality than the actual browser onResponse event)

Original issue reported on code.google.com by Quentin....@gmail.com on 13 Oct 2010 at 8:47

[GoogleCodeExporter]

Original comment by fivefeetfurther@gmail.com on 14 Oct 2010 at 2:41

• Added labels: Milestone-v0.12

[GoogleCodeExporter]

This need, will be solved in: 
http://code.google.com/p/jwebsocket/issues/detail?id=103

Original comment by kyberne...@gmail.com on 30 Oct 2010 at 5:28

[GoogleCodeExporter]

Hi,
For me it's more a specific feature than a global EventManager.
How are you thinking the implementation ?

For me, it's something like: 
sendToken(aToken, new OnResponse { public void onResponse (Token 
aResponseToken) {...}}

How should we use the EventManager to get the answer of a specific token ?
Something like :
EventManager.onResponse(aToken, new OnResponse.{...}) ?
Not sure to understand...

Original comment by Quentin....@gmail.com on 30 Oct 2010 at 10:31

[GoogleCodeExporter]

Hi Quentin,

Sorry if I did not know how to explain properly. When you say "onResponse", you 
are talking about "event". Regardless of the nature of the events, the best way 
to deal with events in a system with connected services is using the "observer" 
pattern, the rest is an abstraction.
Any object can have a behavior that can be observed, and when I say behavior, I 
say "events."

The question is: Do you need to know when a token has been responded? Just 
throw a token event named "onResponse".
- token.fireEvent("onResponse", subject, aResponse)
But maybe in the context of we are speaking, that is too complex and 
unnecessary. So you can then notify the server directly.
- server.fireEvent("onResponse", subject, [aToken, aResponse])
-------------------------------------------------- ---------
Objects with observable behaviors, solve this problem and many more. Is not 
only a global event manager, is about objects with observable behaviors.

Best Regards,
Rolando

Original comment by kyberne...@gmail.com on 31 Oct 2010 at 3:28

[GoogleCodeExporter]

Hi Rolando,
Not sure we need here a observer/observable pattern.
I'll try to explain my point of view:
First, I don't think the "response" event can be attatch to a single token, 
since the same token can be send "n" time to "n" differents websocketConnectors.
Also, a single listener should be enought for this kind of event (because we 
only send a single time the token). 
Since the "response" event is quite different than the others (need to 
implement a queue, flush it after a timeout etc.) with only 1 event attached, 
and in the logic  layer of the server (I mean we are not trying here to 
separate a "view" from the "logic" layer- which is for me the main purpose of 
this pattern-), maybe it's not a good idea to implement it the same way than a 
"generic" event (or maybe a too complex choice ?)
Also, what sounds strange it that it looks like we are trying here to do 
javascript stuff using java. But maybe your examples are just a "global" view ?

What do you think ?

Original comment by Quentin....@gmail.com on 1 Nov 2010 at 11:47

[GoogleCodeExporter]

Hi Quentin,
As I said before, "maybe in the context we are talking about this solution is 
too complex."

I'll just invite you to reflect.
"What happens if you increase the events in the system? For example, and just 
for example: 'token.onDelivered'"
How many components has jWebSockets that may change in the future?"

Of course I was talking about a global view. But I understand, the event-based 
system is much more complex than conventional. The only thing I can guarantee 
is that when the need arises, the system can be fitted satisfactorily without 
many changes.
This is my point of view.

Best Regards.
Remember to reflect about this.

Original comment by kyberne...@gmail.com on 1 Nov 2010 at 12:49

[GoogleCodeExporter]

Ok, I think I understand what you mean.
If I'm right, the "onReponse" feature should be built on the top of a global 
Event architecture.
For instance, when a "response" arrive, we just fire a "onReponse" event with 
this response as parameter. In charge then to the "onResponse-plugin" to catch 
this event and to implement its own logic.
That makes sense.
Not sure to understand where do you place the observer pattern ?
Should I see the EventManager as a main observer, sending "notify" to each 
registred event (observable ?)
Maybe a more concrete example is welcome here, like a quick class-diagram for a 
very simple event ?
Thank you :)

Original comment by Quentin....@gmail.com on 1 Nov 2010 at 1:37

[GoogleCodeExporter]

Basic example using the Groovy language:

interface IObservable
{
  void addEvents(String eventName | Collection<String> eventNames)
  void removeEvents(String eventName | Collection<String> eventNames)

  void on(String eventName, Callable c)
  void un(String eventName, Callable c)

  void fireEvent(Event e, boolean useThreads)
  //Fire the event until a listener offer support to it. Threads are not allowed.
  boolean fireEventUntil(Event e)
}

abstract class ObservableObject implements IObservable {...}

class Server extends ObservableObject {...}
-----------------------------------------------

Server s = new Server()
s.addEvents("response")
s.addEvents(["started", "stop", "restart", "etc..."])
s.on("response", { //A closure. In Java can be a Callable object})
s.fireEvent(new Event("response", s, [aToken, aResponse]), true)

-----------------------------------------------

Now imagine this:
class Engine1 extends ObservableObject {...}
class Engine2 extends ObservableObject {...}
class EngineN extends ObservableObject {...}
class Plugin1 extends ObservableObject {...}
class Plugin2 extends ObservableObject {...}
class PluginN extends ObservableObject {...}
class Filter1 extends ObservableObject {...}
class Filter2 extends ObservableObject {...}
class FilterN extends ObservableObject {...}

And too:
class Token extends ObservableObject {...}
class AnyImportantService extends ObservableObject {...}

-----------------------------------------------

However, these are only assumptions, I have not discussed this with Alex and do 
not mean it will be implemented in this way inside jWebSocket.

What do you think?

A note: Jwebsocket currently have a chain of plugins that are executed when a 
token is received. Using events, only the responsible plugin must be done, this 
would result in improved performance.

Original comment by kyberne...@gmail.com on 1 Nov 2010 at 2:53

[GoogleCodeExporter]

Humm, I'm really not fine with String as event name, just because you never 
knows which string is the correct one, and using string is more the way for 
dynamic typed language, not java.
I think we should implement it as all the others java events we usually use 
(awt, android etc...)
A very quick & draft example:
interface IObservable {
  void addEventListener(EventListener aEventListener) //or a list of event, if needed
  void removeEventListener(EventListener aEventListener) //or a list of event, if needed

  void fireEvent(Event e, boolean useThreads)
  //Fire the event until a listener offer support to it. Threads are not allowed.
  boolean fireEventUntil(Event e)
}
abstract class ObservableObject implements IObservable {...}
------
public abstract EventListener {
  String mUniqueId ;
  EventListener (String aUniqueId) {
    mUniqueId = aUniqueId
  }
  abstract eventFired (Event aEvent) ;
}
--------
public ResponseEventListener extends EventListener {
  ResponseEventListener () {
     super("onResponse");
  }
  eventFired (ResponseEvent aResponseEvent) {
     System.out.println("got a response :)"+aResponseEvent.getResponse());
  }
}
----
ResponseEvent implements Event () {
  Token response ;
  ResponseEvent(Token aToken) {
    response = aToken ;
  }
  getResponse () {
    return response ;
  }
}
----
And then:
Server extends ObservableObject {
    Server s = new Server()
    s.addEventListener(new ResponseEventListener ());
    s.addEventListener(new CustomEventListener () { @Override
        onSmthg (SmthgEvent aEvent) { ...//Do smthg here
        }})
    s.fireEvent(new ResponseEvent(aToken), true)
}

Original comment by Quentin....@gmail.com on 1 Nov 2010 at 3:30

[GoogleCodeExporter]

Hi, I have no any problem with implementation.

The only problem is that when we have 500 events in the system would be 500 
classes and would not make much sense. The system gets a little slow.
But I understand that it is the Java-like way. Remenber that JRE 7 will support 
"Closures".

I told you I'm not very fond of static languages like Java and C #, I prefer 
more flexibility.

I'm glad that you finally understood the idea.

Best Regards.
Rolando

Original comment by kyberne...@gmail.com on 1 Nov 2010 at 3:56