On Sunday 20 April 2008, Bogdan-Andrei Iancu wrote: > [...] > For this there are 2 possible approaches (based on where the command is > implemented): > 1) command resides in dialog and via some callback fetches the > additional info from the above modules (Ovidiu's idea). > 2) command resides in the above module and it will ask dialog module > to provide the dialog description (as MI data) > [...] > > So, IMHO, a better design will be to : > - keep the MI commands in dialog as they are > - implement in the upper modules MI commands that will fetch the > context and the dialog info > - add in dialog API a new function to provide (as MI data) the > description of the dialog (to append the dialog MI description to an > existing MI node) > - keep the MI interface as originally was - accessing the inner data > and part of structure may be dangerous in the future.
Hi Bogdan, hi Ovidiu, the second approachs also sounds more resonable for me, especially in regards to the direction of the data flow and as its not necessary to export internal structures. BTW, in the carrierroute module i uses a somewhat similar logic, even though only on a module level. The function dump_fifo creates a MI tree, adds a node and passes this to another function, dump_tree_recursor, to fill in informations about the routing tables. This functions adds more child nodes in a loop until the whole tree is ready and printed. So a extension of the MI interface should be not necessary. Cheers, Henning _______________________________________________ Devel mailing list [email protected] http://lists.openser.org/cgi-bin/mailman/listinfo/devel
