Confirmed users
2,615
edits
(replies to jcranmer) |
No edit summary |
||
| Line 534: | Line 534: | ||
***'''jminta reply:''' I think this is ok because the forward() method simply returns a steelIMessage that you can modify before you call send(). And since we'll have easy pref getters, applying additional forwarding prefs is simple. | ***'''jminta reply:''' I think this is ok because the forward() method simply returns a steelIMessage that you can modify before you call send(). And since we'll have easy pref getters, applying additional forwarding prefs is simple. | ||
**What is the definition of body? Suppose I have a multipart/alternative message--do we show only the first one? All of them? What about other multipart/s? What happens if I have a multipart/mixed with a Content-Disposition: inline? Need to define attachments a little more clearly here as well. | **What is the definition of body? Suppose I have a multipart/alternative message--do we show only the first one? All of them? What about other multipart/s? What happens if I have a multipart/mixed with a Content-Disposition: inline? Need to define attachments a little more clearly here as well. | ||
***'''jminta reply:''' I'm inclined to just say it's the text representation of the message. For more intricate messages/display bits I think extension authors should use the regular interfaces. Again, if this turns out to be a common use case for extensions, we can expand it, but I haven't seen data to suggest it | ***'''jminta reply:''' I'm inclined to just say it's the text representation of the message. For more intricate messages/display bits I think extension authors should use the regular interfaces. Again, if this turns out to be a common use case for extensions, we can expand it, but I haven't seen data to suggest it | ||
** an enumerator of headers as well as as getters and potentially setters would be a fine thing | |||
=== steelIPerson === | === steelIPerson === | ||