Free bus tickets for everybody

miércoles septiembre 28, 2005 | Event bus | Permalink | Comentarios [7]

First of all I'd like to thank everybody for taking the bus. It's all of you that are making this a fascinating trip!. After that I'd like to say that everybody has a free ticket for this bus. SWT, GTK, QT, wxWindows and even MFC and .NET developers have a free ticket for this bus. This for free for everybody. Although we're focused in a Swing implementation; you can probably apply it to your favourite GUI toolkit, whether GTK or SWT or whatever. Finally if you have trouble with written english then puedes hablar español (yo haría la traducción al inglés si tengo tiempo), podes falar galego se queres, ou podes tentar falar portugués (eu tentarei façer uma traducção) (I'm not very good writting portuguese, though). Vetoing and threading As Nascif clearly explained, the problem with vetoing is that the caller thread blocks waiting for feedback on the event. If the caller thread is the Swing thread (as it is in the current implementation of many buses out there) then the Swing thread blocks. And that's a problem: the whole GUI will freeze. One solution that comes to my mind is making the whole event dispatching through the bus in a dedicated thread (Tim has suggested this too, I think). Nascif has also re-introduced the idea of state machines. As Tim has nicely expressed vetoing is useful for easily handling error conditions. You send the event to the macro-components and you're able to see if the thing worked or not. Take for instance: you send a save action and wait to see if the data was actually saved (or if, on the contrary, an IOException was generated and the data could not be saved). In order to alleviate the thread-wait problem Tim has also suggested sending feedback on success by using an state topic. (Well, I don't know if I'm giving credit to everybody correctly, but you can check yourself in the comments section for the previous post). What I think is a problem with event vetoing is delivering the same event through different actuators/mediators in different threads. In the actual implementation of UITopics you may send an event to topic listeners in different threads (either in the Swing thread or on a worker thread). In the curent implementation it's the topic listeners who are responsible for deciding if they want to receive the event in the Swing thread or in a worker thread. Now, invoking different topic listeners in different threads and waiting for an exception to be thrown (or any other mechanism of vetoing) may be somewhat hard to do. Anyway I'd like to introduce GASM and ASML2 before going any further. I've done some little research and found GASM by accident (Google helping ;-) ). I think it's worth a look before deciding about vetoing and threading. State machines under discussion... or not? Different people have suggested using state machines. After all, since controllers just receive and send events... couldn't they be programmed as state machines? Now, isn't it worth to evaluate how difficult writting state machines in Java is? Isn't it worth evaluating it now, before deciding on vetoing? Isn't it that vetoing is just a fork/join in a state diagram? I'm sure you all agree. Let's be open-minded to different alternatives and, after seeing as many as possible, let us agree on a final decission. So I've found GASM. GASM is defined as "A Formal Method for Specification and Verification". Wow. The "Formal" adjective looks a little bit scary, doesn't it?. "Formal" is usually related to complex things. Maths are formal and are usually difficult to grasp. But "specification" and "verification" sound good. I think I'd like my big Swing application to be as verified and specified as possible. So I entered the GASM Introduction and found that GASM has the following desirable characteristics: precision, faithfulness, executability, scalability, generality and understandability (quoting: "ASM programs use an extremely simple syntax, which can be read even by novices as a form of pseudo-code"). Now, that is interesting. "Extremely simple" and "novices" and "pseudo-code" sound good. Maybe this "formal" thing is not too complex after all. So I kept on reading a little bit more and found that Microsoft research has already defined an Abstract State Machine Language v2.0 that seems to be implemented in .NET. Quoting: "It is an executable specification language based on the theory of Abstract State Machines. The current version, AsmL 2 (AsmL for Microsoft .NET), is embedded into Microsoft Word and Microsoft Visual Studio.NET"... Well, it seems lots of people are working on ASML as a way to formally verify software. It seems Microsoft is embedding powerful state machines in complex GUI software. That's a hint. After all Microsoft Word is a huge GUI application. I think we all would like our big Swing applications being formally verified. Right? So, my final questions (and sorry to just keep doing questions all the time). Shall we go take a look at state machine implementations out there? Give the a try? Or is this just out of scope and we should concentrate on the event bus instead? If defining a state machine in another language but Java, which language should it be? SMC's FSM language (compiled to Java)? Or an interpreted language such as JPython, XML, Groovy or Scheme? I'd appreciate any opinions, suggestions and critics. I'm getting too confused ;-) Thanks in advance, Antonio P.S.: There's no problem in using JDK 1.4. Annotations could be substituted in some way using reflection or other mechanisms when adding/removing topic listeners. The only requirement I can think of is using Doug Lea's concurrent utilities (adopted in JDK 5.0 as java.util.concurrent). P.S.II: Hierarchical listeners: Shouldn't be too difficult to do, I think. What about keeping a topic-listener map in a SortedMap and then using submap to fetch a subset of the map? (The "trie" or "Patricia Trees" data structures could be of help here too, that way you could fire events to "*action" or "file*", this is, by using either suffixes or prefixes).