Hi Dan, So far it was about displaying information regarding dialogs and additional context - no other kind of ops.
I think the main issue is about the "generic" & "low level" support offered by dialog module and if the dialog module shold be aware and do some something for the modules on top of it. I find it non-logical to have dialog module displaying info it does not keep and it does not understand, data form this upper modules ( the dialog context). As said, neither logical, nor from structural point of view i consider the proposed approach suitable. Regards, Bogdan Dan Pascu wrote: > On Sunday 20 April 2008, Bogdan-Andrei Iancu wrote: > >> - if the MI command resided in the dialog module, we will need a >> complex way to select what contexts we want to fetch. Imagine there are >> 2 modules seating on top of dialog module - SST and XXX. So, when >> issuing the MI command to dialog module, which context we should get - >> SST or XXX? >> > > I think this very much depends on what do you intend to do with the MI > command. If the sole purpose is to display some dialog information along > with upper module information (if the upper module registered to provide > such dialog related info), then I see no issue. One only needs to > registers an upper module with a name and a function that provides the > extra information and the dialog module will display any such additional > info under the name the module registered it. However if the intent of > the MI command is more complex, like manipulating information, then I > don't think the dialog module should even attempt to do anything in the > upper module. > > _______________________________________________ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel