Some days ago, while discussing with a colleague, very clever at electronics I must say, I was asking myself how to easily achieve command handling with queues. The goal was to asynchronously post/consume commands to pilot RGB LEDs on a card connected by serial USB connection.
It came to my mind, that I would have to model something first before coding anything ... ;-)
Doing so, I went to think on how to design an application possibly having several "threads" concurrently processing commands posted and/or consumed in queues in transmission (Tx) or reception (Rx).
Here is what I finally got after some time :
The central piece is "CmdEngine" owning Qx/Rx queues as well as a list of events, actually kind of recording what temporally happened in the system.
Okay, this is a model ! Where are the "threads", "synchronized", "volatile" ?
I know, and in first instance, let me tell you that I prefer Jobs to plain threads. As you can see in EngineClient, we introduced an attribute which is actually the core of commands processing ... !
Trust me or not, in conjunction with EMF Transaction and EMF Query, Jobs are simply a very simple and very efficient solution for creating asynchronous applications in Eclipse.
Having simply using code generated from previous model and having built a simple framework using EMF Transaction, GEF and BIRT, I came to build this application in 3 week-ends (A video had been a better demo for something moving) :
This application allows to monitor commands posted on queues all in live !
I created a sourceforge project : xqz.sf.net (xqz is for "Cross Queues"). I also made an RCP application available here. (Thank you PDE Build and JUnit !)
I'm not sure whether or not this could become an Eclipse technology project, but I had a lot of fun to craft all this MDD/EMF(T) stuff.
Eclipse modeling is just so awesome to me sometimes !
Next step record everything thanks to CDO (fingers crossed !)