The subject of this post is the consideration that marrying the subscriber and the deliberator into a single class is a good idea.
I actually think I might have stumbled upon the tail of this idea. I recall momentarily perceiving that it might be necessary a year ago. I was trying to implement the mechanism that helps a Client Device reconstitute as qualia information contained in a transmitter and I remember scaring myself with a very similar set of thoughts I am having now. It appears to me now that perhaps I just wasn't ready to follow this idea at that time; marrying the deliberator mechanism (a type of thinker - a Java thread used throughout the implementation) with the mechanism being considered looked so ambitious at the time that it induced some distraction.
However, the reconstitution mechanism has been stable for some time now, so I think it's now worth to go back and follow a garden path that earlier expediency had caused me to avoid. Hence, I should consider merging the subscriber and the deliberator; it might perhaps complete the implementation of the core concept... or it will merely open up other questions about the core concept that were off in the thicket of enquiry hitherto. In any eventuality, combining the deliberator and subscriber appears to be a very attractive proposition at this point in time.
This all looks to be quite a substantial unit of work unto itself, so I should perhaps obtain a clean working copy of my code before embarking. I'll do that later this afternoon. For now, I'll let these ideas steep for doing this might soften the trauma of implementing them.
