>> I believe the part that worries you the most is the GUI, and I'm with you >> there. Plugins that try to mess around with the GUI suck. I think we'll have >> to define specific points where plugins can easily manifest in the GUI, to >> prevent a big pile of willy-nilly ad hoc crashing dung from ensuing. > > Wait, wait, wait. You want to push a gob of features that REQUIRE UI to > support them into plugins and then you say that plugins that try to mess > with the UI suck? > > Um...you gotta pick one. >
Well, you can have the UI for a generic implementation in the app, and then the plugins adapt it to specific needs. Take labels: if different servers (*cough*gmail) support labels in different manners (or not at all), then we put a UI for adding/browsing labels in the app, and then have a plugin handle the saving of the label data. That uses a plugin to do the work, but the UI is in the app. It does mean we have to carefully consider the plugin APIs and possible use cases, but I'd say we have to do anyway. Just saying "Make it a plugin" without also saying "Here's a way the API hooks might work" isn't very useful. > I'm not maintaining two clients > while you work the kinks out of 1.0 and get a 2.0 release out. I > won't be alone there. What goes in 1.0 is a tradeoff, between sufficient features to justify the product's existence and the time it takes to architect, write, test and document them. I definitely believe we need to make 1.0 ground-breaking in some sense, but pragmatically it will be lacking features people have come to expect. It'll never get finished otherwise. I like the Apple philosophy of do fewer things, but do them really well. That's why the discussions here are working out what the true minimum we can target is. The starting assumption for any feature is that it's not going into 1.0, so that any that is included must really justify its place. _______________________________________________ [email protected] mailing list List help: http://lists.ranchero.com/listinfo.cgi/email-init-ranchero.com
