Currently, we have the exepecteresponse element for a
message. What we should really have are expected
response sets, each of which can contain multiple
messages. The idea is that a message will evoke a
response of one or more messages, but it may not be
that all expected messages will always be returned. For
instance, the Login message will return either a
LogInFailed or a LogInSuccessful, while the
ReloadListenerData messages expects several messages.
We could do this by nesting tags (probably clearest) or
we could do it by by adding a set number to each
expectedresponse tag. For example, here are two ways we
might show that a message will return either foo and
bar, or simply baz.
<expectedresponseset>
<expectedresponse name="foo">
<expectedresponse name="bar">
</expectedresponseset>
<expectedresponseset>
<expectedresponse name="baz">
</expectedresponseset>
<expectedresponse set=1 name="foo">
<expectedresponse set=1 name="bar">
<expectedresponse set=2 name="baz">
We should probably use this system to explictly say
that virtually every message might return a
MessageError message, or something else.
Logged In: YES
user_id=318102
Ok, so there's this other issue I had forgotten about. Some
client messages may tell the server to send messages to
clients other than the sending client. These server messages
aren't technically "responses", so I suppose they aren't an
expected response. But they will only be generated in
response to these client messages, so it seems like we
should explicitly document that expected behavior.
Maybe make a new tag, similar to expectedresponse, but
instead called something like "generates". Or, per my
previous email, maybe these should be set based, so a
message might generate foo and bar, or baz.
It would be nice to say who the generated messages will go
to, but I can't think of a useful way to do that, short of a
text field. Which, come to think of it, might be useful enough.