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
On Monday 21 April 2008, Bogdan-Andrei Iancu wrote:
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
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
Hi Ovidiu,
On the matter of clarity and consistency of the API I agree with Dan, so
here is my opinion on this:
The basic idea is that we have 2 modules (dialog and sst) storing each
some piece of information (dialog info and sst context) - and the goal
is to fetch (via MI) the entire info
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
Hi Ovidiu,
In the end I went through the patches and together with the detailed
explanations I now understand what you try to do. Since this is only a
means for the dialog module to display information about modules sitting
on top of dialog for MI purposes I think it is fine the way it is
Hello Dan,
Initially, I created a separate callback for this job, but in the end
I was just replicating code, and therefore, I merged them. Maybe we
can create two wrappers around the generic dialog callback:
- one would be the existing run_dlg_callback (and keep the existing signature),
- the
On Friday 18 April 2008, Ovidiu Sas wrote:
Hello Dan,
Initially, I created a separate callback for this job, but in the end
I was just replicating code, and therefore, I merged them. Maybe we
I do not think this is about replicating or merging code, it's about
clarity and consistency of the
On Saturday 19 April 2008, Ovidiu Sas wrote:
Well ... this is still a callback, but a different type :)
I would say there is a slight but significant semantic distinction between
them. A callback is something that will be called back when something
happens. This is more like a function from a
Hello all,
For modules sitting on top of the dialog module it is not possible to
retrieve the call specific context out of a callback, mostly because
the pointer to the context is stored inside the dialog callback
structure.
It would make sense to enhance the existing dialog callbacks with a
1. Why does it need to be a callback? Can't it be a query function made
available through the dialog API? I mean if it is a callback at which
point is it called and why do you need it to call back?
2. Maybe it makes sense to have a generic query function, not some MI
specific one, considering
On Thursday 17 April 2008, Ovidiu Sas wrote:
Hello Dan,
This is my the solution to this particular issue. I'm not saying that
is the only one or the best one. I'm quite open to other alternatives.
My goal here was to provide a way to inspect specific call context
inside modules sitting on
Hello Dan,
I think you misunderstood my goal here.
I want _from_ the dialog module to access the internals of other
modules sitting on top of the dialog module. That's why I need a
callback.
I don't intend to access the dialog internals from other modules
(which could be done via the dialog API,
On Thursday 17 April 2008, Ovidiu Sas wrote:
Hello Dan,
I think you misunderstood my goal here.
I want _from_ the dialog module to access the internals of other
modules sitting on top of the dialog module. That's why I need a
callback.
I don't intend to access the dialog internals from
Well ... define generic.
This particular callback is meant to be used via the MI interface.
You can define other type of callbacks and reuse the extra pointer
that was defined (see void **x_param inside struct dlg_cb_params).
Regards,
Ovidiu Sas
On Thu, Apr 17, 2008 at 4:48 PM, Dan Pascu [EMAIL
On Thursday 17 April 2008, Ovidiu Sas wrote:
Well ... define generic.
This particular callback is meant to be used via the MI interface.
You can define other type of callbacks and reuse the extra pointer
that was defined (see void **x_param inside struct dlg_cb_params).
That's exactly my
Hello Dan,
The problem that I'm trying to solve was described at the beginning of
this thread, maybe with not enough clarity (please follow also
http://sourceforge.net/tracker/index.php?func=detailaid=1933630group_id=139143atid=743022).
I will use as an example the sst module. The sst module
Forgot to mention, the callback is generic and it can be used by any
module sitting on top of the dialog module.
In the extra pointer from the callback structure I expect to find a
pointer to a mi_node structure (which is not module specific). Each
module is responsible of providing it's data in
see inline
On Thu, Apr 17, 2008 at 6:52 PM, Dan Pascu [EMAIL PROTECTED] wrote:
On Friday 18 April 2008, Ovidiu Sas wrote:
Hello Dan,
The problem that I'm trying to solve was described at the beginning of
this thread, maybe with not enough clarity (please follow also
19 matches
Mail list logo
