On 26/gen/2010, at 01.21, Olivier Scherler wrote: > I have to say I agree with John C. Welch on the plugin issue. For one thing, > it's too easy to relegate a given feature to a hypothetical plugin (that > might be distributed by default, or not, or distributed by default and not > uninstallable, or not, let's decide at the last minute), to defer having to > decide whether it's a core 1.0 feature or not. > > If we go too far down this path, then Letters will be a mail client that > suits only the casual users (or maybe not even) in its stock distribution, > forcing the intended audience to carefully select the plugins they need from > what will likely be a vast, motley list, to make it worth considering over > Apple Mail. Not only would you have to find whether a plugin exists that does > what you want, but you could have to choose between two plugins that provide > said feature differently. What a nightmare.
First of all: I *completely* agree about the high design quality we need to reach. It's my first objective here. ;) Then... to me it feels that it's missing a "third option" in this discussion, while I think it's something touched by everybody. I think that a good approach could be: 1. Build a solid and well defined plugin framework 2. Build core functions on it This means having three different levels: Level 1, "Core": LetterBox (IMAP, cache, networking, etc), basic UI, plugin framework, smart folders engine, keyboard navigation, AppleScript integration, ...and something else to be defined -> TEAM: Letters Core Team Level 2, "Core Plugin(s)": almost everything on top of the barebone "Core", from list style, to workflow, to special folders, to different layouts, to badges. Those plugin(s) are probably impossible to disable, probably easy to update. -> TEAM: Letters Front Team Level 3, "Plugins": anything else -> TEAM: the whole community. L1+L2 == Letters I think that you could think Core + Core Plugin(s) like XULRunner + Firefox. I think that this approach will solve any problem: a. the app will be well designed and mantained: the Core Plugin(s) *ARE* the Letters application. b. it will assure that the plugin framework is polished, stable and powerful. c. it will allow different teams working on their specialities d. it will allow community support Probably this approach has just one huge issue: it may be really, really, really, really hard to make a plugin framework deep enough inside the Core to make a good split between Core and Core Plugin(s). What do you think? Is it possible? Does it address the problems raised so far? |D _______________________________________________ [email protected] mailing list List help: http://lists.ranchero.com/listinfo.cgi/email-init-ranchero.com
