Free bus tickets for everybody

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).

Comentarios:

Antonio,

Quick Comment until I digest everything else.

I don't think there would be a problem to wait on the Swing thread (or pseudo waiting as I call it) Check out Foxtrot, or Spin, (or design it yourself it's pretty easy). They show how to allow the invocation of an async task from the EDT while maintaining flow control on the EDT (and dispatching events)

Tim

Enviado por guest en septiembre 28, 2005 a las 04:04 PM CEST #

<hr> Ola' Antonio, <p/> (Escrever em Portugues e' ruim por causa da falta de acentos nos teclados configurados para Ingles, imagino que Espanhol tenha o mesmo problema... ;-) <p/> I think we should keep the focus on the Event Bus implementation and take on State Machine languages later, or on a separate project. It is after all a self-contained problem - the bus doesn't care how the controllers/actuators deal with the events. I know it is cool but it might become a large project in itself. I suggest we keep the focus narrow and get some code out quickly so we can start playing with it. <p/> Regarding vetoing, what if we implement a special kind of event that carries a Slot? . The event sender would block "taking" from the response slot, waiting for a response to come back - for example, either a "file saved" or an I/O exception encapsulated in a response event. This of course assumes that only one event consumer is responsible for sending a reply back; things would get complicated if you can be vetoed/approved by multiple components. <p/> This approach would work better with a thread pool to process the events, like a PooledExecutor . I would rather not mess with the EDT on a first pass, and just assume that only Controllers send vetoable events - is it a fair assumption?. Later we could try to adapt or incorporate something like FoxTrot. <p/> Something to keep in mind is that by using a thread pool, events might get delivered out-of-order. This might or might not be a problem... adding a timestamp to events could help debugging any potential issues. <p/> --Nascif

Enviado por guest en septiembre 28, 2005 a las 10:10 PM CEST #

The bus event is much less interesting with incoporating the state affaire.

Enviado por guest en septiembre 28, 2005 a las 10:25 PM CEST #

Hi,

Yes, you're probably right: it's too early to think of state machines around. Maybe that's a different project on top of the bus.

Coming back to the threading issue. Actuators should run in the EDT thread, I assume. After all those manipulate GUI components. What I mean is that actuators should receive events in the GUI thread.

But all other event handling (including controllers) could easily run in another thread. (UITopics has already an Executor to spawn worker threads).

Now should all controllers run in a unique thread or on different threads? I don't think that controllers "waiting" for feedback (veto) from actuators is an issue. After all waiting for feedback is probably a business requirement too.

Now, Tim has pointed out a good hint: foxtrot doesn't wait for callbacks to finish: it delivers in a thread and keeps on receiving new events from the bus. That's something to investigate too.

I'll keep on thinking on this (too busy at the moment).

Thanks for feedback. <em>Muito obrigado</em>,
Antonio

Enviado por Antonio en septiembre 29, 2005 a las 02:48 AM CEST #

I think the EventBus is the right way to go on this one, simple and easy to understand. You could call it the "Magic Bus" in honour of Who song of the same name!!

Enviado por Tim Osten en septiembre 29, 2005 a las 07:19 AM CEST #

Yes! I like the "Magic Bus" idea :-D.

(I was thinking of another one (local singer) but it's probably not a good idea to post the song name here ;-))

Cheers,

Antonio<p

Enviado por Antonio en septiembre 29, 2005 a las 02:28 PM CEST #

<hr/> More food for thought - maybe a little too detailed for this phase, but here it goes:
  • 1. Queue archtecture:
  • How many event queues and how are they mapped to topics?
    • 1.1 One queue for all topics
    • Very simple, allows one thread to service all event transfers (with the help of SwingUtilities to dispatch events in the EDT).
    • 1.2 One queue for each topic
    • May create concurrency issues but allows for the easy implementation of 2.2 below.
    • 1.3 Two separate queues, for application and component events
    • Just a slightly optimized version of 1.1
  • 2. Delivery failure policy:
  • What happens when an event is sent to a topic for which there are no registered consumers? Could happen in a race condition scenario.
    • 2.1 Discard
    • Event is logged and discarded. Has to be watched for during the testing...
    • 2.2 Store
    • Event is kept in a queue until a listener arrives. This is the model used by JMS and the CORBA Event service, I believe.

Enviado por Nascif A. Abousalh Neto en septiembre 30, 2005 a las 09:35 AM CEST #

Enviar un comentario:
Los comentarios han sido deshabilitados.
About

swinger

Search

Archives
« abril 2014
lunmarmiéjueviesábdom
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Hoy