I'm going to spitball some ideas here. I have not attempted the conversation part of this but I have been very successful with the dynamic loading and abstract classes (and i hear LV 2014 will make this easier with some new packed project library options)
Statically linking messages may be the first of your issues. If you could dynamic load messages using the encoding that AQ mentioned then deserialize the actual message data into the class, that would be a step in the right direction. At that point, all dynamically loaded messages would need to be a child of some abstract message that you main applications (client or server) could statically link to, I.e. the Do.vi
The beauty part of classes are their ability to override default behavior via Dynamic Dispatching rather than having to add a new method for each message.
You will also need an API to extract/inject the information from your client and server or mainly just the server. This API will need to be separate from you application, but both your application and conversation modules will need to reference this. That way you can build new conversation modules for the server without statically linking them inside the server application.
Now on both ends the conversation module would need to be implemented, once on the client to request/receive information and once on the server to receive/reply. Once the app is compiled, adding conversations, would be as easy as building a client side and server side conversation handler. Using AQ's suggestions for encoding something like this might occur "AA:How are you today?". The server would load AA class dynamically and send the remaining parts of the string to the deserialize function, AA class would take the message "How are you today?" and reply "AA:I am very good, Thank you!". On the client side, the client would load AA dynamically and deserialize the remaining part of the message and invoke some message in the API or inject the data to some VI in the API.
Obviously the AA Classes on the client and server end would have different implementations and possibly methods for send and receive or receive and reply, but i think i got my idea across.
Keeping the class names the same on both ends will help keep which client message corresponds to which server message, we'll just call it a conversation. This may be bad because having two classes in memory of the same name is not a good idea unless scoped differently via a library.
I have not talked about the API to extract/inject data into either client or server, and I'm not going to since it is our of scope of the main discussion.
Since we have the ability to dynamically load messages and inject/extract data from an application, we can now create new conversations without changing at least the server side application. The client would either have to be scripted to initiate new conversions or statically linked to the messages of the conversion. Otherwise who would initiate the conversation?
Let me know if i'm crazy, so i don't attempt this in the future.
