I've been trying to wrap my head around getting real synchronicity and clean threading.
I've been dying to find examples of something done the way I'm doing it. To no avail.
IRC should be a good example of things, right?
But so far as I can tell, IRC is asynchronous in status replies. If you send a command and it doesn't work.... you may well get a "chat" message before getting the "error" message. Unlikely, but possible.
Is this really so horrible? It seems like it should be, my guts wrench... but... IRC is quite successful. It doesn't seem to be such a big deal.
I really want to do right by this system, though -- plain text yet computer decipherable replies are made to EVERY command, whether they worked or not and if not some message explaining why not... just in case such a thing should be trickled up for the enduser to see... so I'm worried about receiving a message inbetween a command being sent out and the reply to that command being returned.
of course, I could just add a state to say "queue messages until reply comes in"... or I could handle such things asynchronously, keeping track of the fact that I was expecting an answer to something and jumping back to that bit of code if/when the reply comes...
what I've been working on, though, is setting up TWO channels of conversation... opening two sockets for each client... and tying them together... it's a little ugly, but... it "feels" right. just not entirely, or I wouldn't be blathering about it here, hoping for a saviour to sweep down and bless me with The Right Way To Do It. Presuming there is a best answer... which is not necessarily a fair assumption.
I should be coding, not whining. I think I'll go to sleep.