3.2.1.1 Subscriptions
IMAP clients such as Mulberry have the ability to mark a set of mailboxes as 'subscribed'
mailboxes. The IMAP client can send a specific request to the IMAP server to get the list of
subscribed mailboxes. It is up to the IMAP client to decide how to present this subscribed
mailbox list to you. Mulberry makes use of the subscribed mailboxes feature to allow you
to create a set of mailboxes that always appear at the top of the mailbox list. This is useful if
you have a set of mailboxes that you frequently use and want quick access to in the server
window.
It's possible to configure Mulberry to check any mailboxes for new messages at different intervals without subscribing to them. It's also possible to configure it not to check for new messages in subscribed mailboxes. That granularity of configurability is very useful to me. Many people don't realize such things are possible because their mail clients don't offer those capabilities.
Earlier, minkie wrote:
One of Mulberry's failings was to expose all of the underlying complexity to the user.
Indeed. Mulberry's obscurely powerful and powerfully obscure interface overwhelmed and intimidated many users, often before they barely scratched the surface of its capabilities. I've witnessed many Mulberry novices initially frustrated by or criticizing certain Mulberry features and behaviors, only to later change their minds when they understood the intended purpose and stopped perceiving them as gratuitous baggage. Eventually, some features became so useful that mail clients lacking them seemed inferior. Of course many people just threw in the towel early, long before the opportunity for those "ahha moments" arrived.
That's all moot now. Frankly, I'm not surprised Mulberry couldn't survive. I had more serious doubts after Apple's announcement of its transition to Intel. It would have been a significant undertaking migrating Mulberry's Mac OS codebase from CodeWarrior to Xcode, which we now know was something ISAMET/Cyrusoft couldn't afford to do for the affected subset of its total customers (whatever percentage that was). Plus mail apps and web browsers are commodity software, with the mainstream public expectation they be freely available (with exceptions like Eudora, but that's not Qualcomm's one-trick pony). And RSS/Atom feedreaders now seem on the road to commoditization.
To the guy referring to those of us who'll miss Mulberry as "poor slobs", thanks for the blind insult that's nearly guaranteed with a visit to/.
Mulberry treats IMAP, POP3, SMTP, and other accounts separately. Identities only specify (or inherit) an outgoing SMTP account; there's no reason addresses in those identities need incoming IMAP or POP3 account info. An "account" in most mail clients contains both SMTP and IMAP or POP3 info, which is less flexible (and more frustrating) than Mulberry's method of using identities.
External mail filters like procmail can add messages to mailboxes you want to check without subscribing to them. Control over which mailboxes are checked when can be important. That's seriously lacking in Apple Mail, for example.
How's mutt's IMAP support nowadays? Last I checked (a couple years ago?) it was still pretty limited. Heck, I'll just grab the current mutt and test it myself.
And Mulberry's ability to differentiate "recent" and "new" messages in mailboxes can be useful for monitoring.
Any mail app developers lurking here? If we create you a laundry list of Mulberry's unique, "must-have" features would you consider integrating them into your app?:-)
Re: And it lacks Mulberry's novel separation of the concepts of identity and account.
That's one of Mulberry's unique features that's made it trivial to use dozens of mail addresses in several domains with different accounts. Is there any IMAP client (for OS X in particular) that has that sort of identity/account separation? If/when I'm forced to abandon Mulberry (e.g. buying an Intel-based Mac in a few years) I really hope by then there's an IMAP client that doesn't require creating "dummy" accounts just to use different mail addresses.
Mulberry certainly has its shortcomings but it's clearly superior in many ways to other mail apps I've used. ISAMET/Cyrusoft's closure is unfortunate, but maybe it can have a positive side effect of bringing overdue attention to some of Mulberry's strengths that other mail app developers will notice and implement.
Lastly, mulberry-discuss list has remained one of my favorites for several years. The sophisticated depth of knowledge and information shared there is always a refreshing change from the "newbie noise", immature mudslinging, and excessively cynical banter on too many other support/discussion lists and forums. It's definitely a been class act that I'm sure many of us who've participated there will miss. And a much deserved big thanks to Cyrus Daboo for his passionate dedication to Mulberry and its support over the years.
Yep, but I'd much prefer calling them something like message groups, conversation collections, smart labels, or anything other than folders.
Using the folder analogy inherited from the physical object is bogus when a unique message appears within multiple groups, like one iTunes library track appearing in different playlists. In real-world folders you'd be reproducing multiple physical copies (clones) but each can be individually modified and become distinct from the original.
If nothing more, I see Gmail as opening a door for the "mainstream" webmail user to view/search/organize/store e-mail messages using abstractions beyond the ever increasing limitations of traditional folders. Folders become simply a subset and arbitraryconvenience within these more powerful methods, which will extend into more applications/services in the future (like we've tasted with [smart] playlists/albums in iTunes/iPhoto). That's what makes Gmail exciting (and important) for me.
I've been curious to try Bloomba but there's no Mac OS X client for it (yet).
Slashdot Mirror
From the Mulberry Reference Guide:
/.
3.2.1.1 Subscriptions
IMAP clients such as Mulberry have the ability to mark a set of mailboxes as 'subscribed' mailboxes. The IMAP client can send a specific request to the IMAP server to get the list of subscribed mailboxes. It is up to the IMAP client to decide how to present this subscribed mailbox list to you. Mulberry makes use of the subscribed mailboxes feature to allow you to create a set of mailboxes that always appear at the top of the mailbox list. This is useful if you have a set of mailboxes that you frequently use and want quick access to in the server window.
It's possible to configure Mulberry to check any mailboxes for new messages at different intervals without subscribing to them. It's also possible to configure it not to check for new messages in subscribed mailboxes. That granularity of configurability is very useful to me. Many people don't realize such things are possible because their mail clients don't offer those capabilities.
Earlier, minkie wrote:
One of Mulberry's failings was to expose all of the underlying complexity to the user.
Indeed. Mulberry's obscurely powerful and powerfully obscure interface overwhelmed and intimidated many users, often before they barely scratched the surface of its capabilities. I've witnessed many Mulberry novices initially frustrated by or criticizing certain Mulberry features and behaviors, only to later change their minds when they understood the intended purpose and stopped perceiving them as gratuitous baggage. Eventually, some features became so useful that mail clients lacking them seemed inferior. Of course many people just threw in the towel early, long before the opportunity for those "ahha moments" arrived.
That's all moot now. Frankly, I'm not surprised Mulberry couldn't survive. I had more serious doubts after Apple's announcement of its transition to Intel. It would have been a significant undertaking migrating Mulberry's Mac OS codebase from CodeWarrior to Xcode, which we now know was something ISAMET/Cyrusoft couldn't afford to do for the affected subset of its total customers (whatever percentage that was). Plus mail apps and web browsers are commodity software, with the mainstream public expectation they be freely available (with exceptions like Eudora, but that's not Qualcomm's one-trick pony). And RSS/Atom feedreaders now seem on the road to commoditization.
To the guy referring to those of us who'll miss Mulberry as "poor slobs", thanks for the blind insult that's nearly guaranteed with a visit to
Thanks for that info.
Mulberry treats IMAP, POP3, SMTP, and other accounts separately. Identities only specify (or inherit) an outgoing SMTP account; there's no reason addresses in those identities need incoming IMAP or POP3 account info. An "account" in most mail clients contains both SMTP and IMAP or POP3 info, which is less flexible (and more frustrating) than Mulberry's method of using identities.
External mail filters like procmail can add messages to mailboxes you want to check without subscribing to them. Control over which mailboxes are checked when can be important. That's seriously lacking in Apple Mail, for example.
How's mutt's IMAP support nowadays? Last I checked (a couple years ago?) it was still pretty limited. Heck, I'll just grab the current mutt and test it myself.
And Mulberry's ability to differentiate "recent" and "new" messages in mailboxes can be useful for monitoring.
:-)
Any mail app developers lurking here? If we create you a laundry list of Mulberry's unique, "must-have" features would you consider integrating them into your app?
Re: And it lacks Mulberry's novel separation of the concepts of identity and account.
That's one of Mulberry's unique features that's made it trivial to use dozens of mail addresses in several domains with different accounts. Is there any IMAP client (for OS X in particular) that has that sort of identity/account separation? If/when I'm forced to abandon Mulberry (e.g. buying an Intel-based Mac in a few years) I really hope by then there's an IMAP client that doesn't require creating "dummy" accounts just to use different mail addresses.
Mulberry certainly has its shortcomings but it's clearly superior in many ways to other mail apps I've used. ISAMET/Cyrusoft's closure is unfortunate, but maybe it can have a positive side effect of bringing overdue attention to some of Mulberry's strengths that other mail app developers will notice and implement.
Lastly, mulberry-discuss list has remained one of my favorites for several years. The sophisticated depth of knowledge and information shared there is always a refreshing change from the "newbie noise", immature mudslinging, and excessively cynical banter on too many other support/discussion lists and forums. It's definitely a been class act that I'm sure many of us who've participated there will miss. And a much deserved big thanks to Cyrus Daboo for his passionate dedication to Mulberry and its support over the years.
Yep, but I'd much prefer calling them something like message groups, conversation collections, smart labels, or anything other than folders.
Using the folder analogy inherited from the physical object is bogus when a unique message appears within multiple groups, like one iTunes library track appearing in different playlists. In real-world folders you'd be reproducing multiple physical copies (clones) but each can be individually modified and become distinct from the original.
If nothing more, I see Gmail as opening a door for the "mainstream" webmail user to view/search/organize/store e-mail messages using abstractions beyond the ever increasing limitations of traditional folders. Folders become simply a subset and arbitraryconvenience within these more powerful methods, which will extend into more applications/services in the future (like we've tasted with [smart] playlists/albums in iTunes/iPhoto). That's what makes Gmail exciting (and important) for me.
I've been curious to try Bloomba but there's no Mac OS X client for it (yet).
An older, but still interesting article: UNIX Advisory Locking...