Hello all,
I was wondering about the scalability of SSSAD. While it is probably
not an issue when only a small number of parameters are being used,
what would happen when you are creating objects that, themselves,
create many parameters?
I was noticing that any time I make a change to any of the parameters
under SSSAD control, a message gets sent to EVERY OTHER parameter,
whether or not it is of the same key. Many of those messages get sent
only to be rejected.
I was wondering how it might effect things that instead of having the
SSSAD bus at all, that a message point would be created for each
parameter. We already know that a parameter has a specific unique key,
so why not use that to send messages to to change the value of the
parameter? It would reduce the number of messages being sent.
So, basically, the two things that have changed here is that the SSSAD
bus get eliminated, and is replaced by sending a message directly to
the parameters key, and in the "loading" process, instead of sending
the messages to SSSAD, you would use the first parameter in the saved
data stream as the place to send the parameter.
I tried to mock up what I am talking about, and have attached it to
this email. As far as I can tell, this should be functional
replacement for SSSAD, with the exception of having to send the
message to the key, rather than SSSAD.
Mike
PS, if you find this useful, please don't start to use it, as I don't
think we really need an alternative to SSSAD, I only make this
proposal to see if it would be worthwhile to modify SSSAD.
--
Douglas Adams - "I love deadlines. I like the whooshing sound they
make as they fly by."