Bundles have long needed some extra metadata to improve its
presentation in aggregated contexts.
Here are what I suggest we add to the `info.plist`:
* Category
* Dependencies
* Description
* Maintainer
* Technology URL
* Status
What follows are some comments about each of these fields.
Please don’t hesitate to comment on this proposal.
# Category
Eventually I want 99% of the bundles disabled by default, and have
the user start out by picking what he needs. Since there are >100
bundles, there needs to be some organization.
The categories I had in mind was:
1. Markup / Prose
2. Programming
3. Framework
4. Build System
5. SCM System
6. Utility / Other
In addition I also think it would be useful if each bundle had an
embedded thumbnail to be used for such display purposes. E.g. the
Ruby on Rails bundle would embed the RoR logo etc. We probably do
not need a key to specify the path of such resource but instead could
just always require it was there as `Thumbnail.«type»`.
# Dependencies
An array of bundles that this one builds on. For example Ruby on
Rails requires the Ruby bundle. This is useful when installing a
bundle via a wizard.
# Maintainer
This is the maintainer of the bundle in the venerable `full name
<email>` format. Likely we should ROT13 encode this field, as the
`info.plist` will often be available over http.
I deliberately avoided the use of author, since many bundles receive
work from many contributors, and so if this was `author`, the list
would probably be monotonically increasing.
I think a bundle should only have one maintainer. True in practice we
have bundles maintained by several people, but the main purpose of
this field is to list someone the user can contact about the bundle.
If there are two maintainers, listing both will just “confuse” the
user as to who he should write, and there is only a 50% chance he
will actually write the one responsible for the thing he writes about.
Comments on this one? We could always make it an array, so we at
least have the option, but lets keep the name of the key in singular
form.
# Description:
The oft requested description. I second the suggestion (from the
thread started by Sebastian Gräßl) that this should be Markdown. We
do need a semi-rich description language to be able to embed hyper
links etc.
# Technology URL
A better name for this key is definitely required.
This should link to the technology that the bundle adds support for.
E.g. the svn bundle would link to http://subversion.tigris.org/, the
Markdown bundle to http://daringfireball.net/projects/markdown/, etc.
Might be a little ambiguous with things like the SQL bundle.
Sure the technology link could easily be in the description, but by
having it as a separate key we ensure that bundle authors do not
forget to fill out this info. It also allows a uniform presentation
of this link, which might benefit the user when skimming over bundles.
# Status
The status of the bundle should probably be something like stable /
unstable. Not entirely sure, especially since we do not branch
development and release bundles.
_______________________________________________
textmate-dev mailing list
[email protected]
http://lists.macromates.com/mailman/listinfo/textmate-dev
