4 Oct
2005
4 Oct
'05
7:31 a.m.
On Mon, Oct 03, 2005 at 07:59:59PM -0400, Paul Davis wrote:
i consider that the CV never considers changes
to have been carried out just because it asked. anything else is not
really MVC. maybe the change requested by CV is not possible for M at
this time.
Good point. So this means that when M refuses a new value, it should
respond by sending the current value at least to the originator of the
request. In some cases (e.g. a slider) the C and V elements are the same
(the slider's knob), which amounts to an implicit assumption by CV that
its request will be accepted. So a slap on its hands by M is the only
way to correct such hubris.
void handle_model_state_change()
{
change_my_view_state_value (the_model_state->value);
}
void change_my_view_state_value (float newval)
{
if (my_view_state->value != newval) {
my_view_state->value = newval;
send_change_to_model (my_view_state->value);
}
}
this causes one extra "cycle" in any state change, but ensures absolute
agreement between V(C) and M. notice that C and (indirectly) M can both
use change_my_view_state() to achieve their goals.
Interesting. I'll have to go through some mental exercise to convince myself
that this will never cause infinite cycles.
Dave Robillard wrote:
After much fiddling around with ugly schemes to not
send replies to
certain clients in Om, I just echoed back /everything/ to all registered
clients, and left it up to the client to deal with it. The comm layer
is much simpler and understandable because of it.
... Generally when given the choice I'll choose complexity in the client
over complexity in the engine any day.
Thanks to both of you for your response. So at least two experienced
developers agree that updates should go to *all* clients, and that a client
can be expected to handle this gracefully. Since that was my position from
the start, I'll join the club :-)
--
FA