> > > > In GMS I've not only the engine serving request out of the GUI, > > but also the other way around. Like when the processing part > > detects a data flow which is a deadend, it will trigger an event > > in the GUI. I can imaging various other random events inside the > > VSH PL and BL that need to be passed to the DL and UI. > > I'm wondering if Loci allowes such abilities? Or should I put all > > the logic for handling the error\notify events inside the BL? It > > seems a good thing, and I'm willing to implement it, but I needs > > some feedback first ofcourse :) > > You're aware that Loci's front 'listens' to a stream of XML commands from the > middle. All communication, including that of unexpected error messages, > travels through that stream. > No, I didn't knew that.. so there's no problem. Good. I leave gms\BL the way it is now, you do so 2 and we only need to define the communication some day. Not now please :-) I'm just orientating if we still have mayor design differences. > But, right now the mechanism is not threaded. So, the middle literally cannot > do anything until the front issues a command, and visa versa. And I believe > the front doesn't listen for unexpected messages (is that right, Brad?). IOW, > the middle cannot YET trigger an event in the front. It was planned, though. That is enough for now :) > I don't know if the logic for this belongs in the DL or BL. But, of course, > the communication should pass through the DL before going to the front. > I think events once they are triggered in a layer, it will 'travel upwards' to the UI. But it might be handled by a layer before it reaches the UI. jarl