In quite a few of the long threads there's been a lot of ideas thrown around
that would be good plugins. And while I agree with most of them, I don't want
us to end up going down a path of dismissing a feature by saying, "That can be
a plugin."
Yes, that *can* be a plugin, but that doesn't mean we don't have to consider
the application making the tools and data and metadata available to make such a
plugin possible.
If we want plugins to be able to change the look of the app, we need to expose
the apps UI look somehow. If self-updating address book entries are going to be
a plugin possibility, then the code to get to the address book and modify it
has to be accessible to the plugin.
So yes, let's keep the ideas coming and yes let's acknowledge that many of
these are suitable for plugins but let's not lose the focus that all these
plugin ideas need to be kept in mind when actually coding.
I think that a task for the developers is going to have to be to consider how a
plugin is going to access every method, ever object, every datastore and that
if something is NOT accessible by a plugin, then there needs to be a really
good reason and quite a lot of discussion.
I think for Letters to really succeed it needs to not only be powerful and
Mac-like, but it also needs to be so extensible that people will be left in
slack-jawed amazement at what it is able to do.
--
Rincewind had always been happy to think of himself as a racist.
The One Hundred Meters, the Mile, the Marathon -- he'd run
them all.
_______________________________________________
[email protected] mailing list
List help: http://lists.ranchero.com/listinfo.cgi/email-init-ranchero.com
