FETCH response data items should not be UntaggedResult
Closed this issue · 5 comments
Why are FETCH response data items (msg-att) simple UntaggedResult constructors instead of their own data type?
Given that msg-att can only appear in a FETCH response line, I think it makes sense for the fetch response to be something like Fetch Int [MessageAttr] where MessageAttr is something like:
data MessageAttr = MsgFlags ... | MsgEnvelope ... | MsgSize ... | MsgBody ...
The reason for that is to allow for message streaming using the ListT interface - the user can observe a series of UntaggedResults and a final TaggedResult specifying a final status. While I agree UntaggedResult is a little bit too general, I didn't want to duplicate data constructors, various attributes seem to be allowed both inside a fetch reply and other reply types https://tools.ietf.org/html/rfc3501#section-2.3
I don't think what I said will affect streaming at all. I'm just talking about reorganizing message attrs, which are already coming back on the same FETCH line, into a different type.
I'm not sure what the shared attributes are... 2.3 just gives a description of all the attributes.
My reading of the RFC seems to suggest that message attributes are only returned in FETCH responses.
You're very right, I missed it when writing the library. Would you have the bandwidth to add it?
I don't think I'll have time to do this. I chanced upon this library and thought I'd play around with it, but don't really have much time to spare.
I got back into this code and I know why I did it that way. Basically because untagged replies are not bound to a command and are just flowing from the server, we would get crazy race conditions when commands are posted concurrently.
If you post a fetch and a find, but the fetch returns it's untagged replies first, you would get those untagged replies as a response to find. This is all right really, if you implement your handlers to react to an untagged reply type and not to an originating command. The alternative here is a lot of code to heuristically bind untagged replies to a command they may originate from, but that I don't have the capacity for at the moment.