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
