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.