User:Jminta/Steel: Difference between revisions

Jump to navigation Jump to search
no edit summary
(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 ===
Confirmed users
2,615

edits

Navigation menu