<html>
<head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body style="font-family: Lucida Sans; font-size: 16px;" bgcolor="#FFFFFF" text="#000000">
<font face="Lucida Sans" size="3">
<div style="font-family:Lucida Sans;font-size:16px;">One thing I
disagreed strongly with regarding the new "direction" for
Thunderbird was an overall opinion that Thunderbird was
"stagnating".. <br>
<br>
Looking over the add-ons directory, I find that Thunderbird is a
vibrantly growing system with many core features being placed
there. For example, there is a wonderful manage SIEVE plugin.
And it is precisely where it should be - in the add on's
directory because not everyone has a sieve supporting server.<br>
<br>
Where I find Thunderbird to be stagnating is that the directory
can be hard to go through and find collections of extensions
that integrate well together. At the same time - certain
popular extension developers should be polled on what would make
their system easier to code for.<br>
<br>
Again, going back to SIEVE - what is the functionality of
SIEVE? It's a filter manager...so if there was a more
convenient API in filter management to allow maintaining both
external and internal filters using the same interface that
would be a plus - which won't appear as a feature to the end
user - but could be used to promote other features. [For
example, if the Filter app had API's useful to SIEVE, those same
API's would be usable for a GMAIL filter manager... GMAIL
filters are editable via API, there just is a change in
terminology. Trying to write a full featured filter manager
would be a pain, but if half the work is in the TB API then it
can be pushed out.<br>
<br>
To that end, I agree about 75% with the idea of pushing new
features into add ons - where I disagree is that for the small
bit of code which would be best off in core code to generalize
an api for the function.<br>
<br>
As an example, you send it is an cool little feature - but the
way it was written, if someone else wants to store files on a
different service they need to write a completely new add on.
If instead a generalized file handling API had been placed in
the core code, while the you send it specific code was in the
official add on directory - that would likely have sparked a
dozen more add ons providing similar functionality - which leads
to growth and best practices being created - instead of odd
little features only a few people use.<br>
<br>
</div>
</font>
<img src="http://mandrillapp.com/track/open.php?u=11000867&id=2d715f68f502464eb99b4fdb59cdd0ae&tags=252069,991761" height="1" width="1"></body>
</html>