289
edits
User:Jminta/Steel: Difference between revisions
Jump to navigation
Jump to search
replies to jcranmer
No edit summary |
(replies to jcranmer) |
||
| Line 528: | Line 528: | ||
*jcranmer: Rather long list; sorry if it seems like I'm being a tad specific here, but I'm thinking more from an implementor's point of view... | *jcranmer: Rather long list; sorry if it seems like I'm being a tad specific here, but I'm thinking more from an implementor's point of view... | ||
**Perhaps have both a MIME view and an attachment view? Some users may prefer just getting a list of all attachments (needs to be somewhat more rigorously defined) while others may want precise MIME multipart access. | **Perhaps have both a MIME view and an attachment view? Some users may prefer just getting a list of all attachments (needs to be somewhat more rigorously defined) while others may want precise MIME multipart access. | ||
***'''jminta reply:''' This is starting to feel a bit too technical for entry-level extension writers. If you can show me basic extension plans that involve mime-specific stuff, I could be persuaded though. | |||
**Generic header get/setters. sync may be problematic here: IMAP/NNTP will not have these headers available by default except under certain circumstances. | **Generic header get/setters. sync may be problematic here: IMAP/NNTP will not have these headers available by default except under certain circumstances. | ||
***'''jminta reply:''' Yeah, I'm starting to come over to the side of basic header manipulation, even though I consciously left it off in the beginning. | |||
**The forward method may want to be somewhat more fine-tuned (i.e., potentially overriding forward preference settings). | **The forward method may want to be somewhat more fine-tuned (i.e., potentially overriding forward preference settings). | ||
***'''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. | |||
=== steelIPerson === | === steelIPerson === | ||