Adding methods is no problem - removing or altering them is.
Should be no problem if you are still in beta.
Are you sure? I would think youd need to create a new interface so that applications that get your interface have an expected set of APIs to use. ie, if you get the interface x, you can assume that function foo exists. If 'foo' was introduced later, the application would crash trying to call it. It has no way of determining what functions exist other than some kind of version call. To do away with version tracking, you simply try get the interface number as high as you need, and can assume a certain level of functionality on that interface.
Take a look at IContextMenu,2,3, all they've done is add new methods.
Its not really in beta anymore, as it has been released to the plugin site at v1. In these forums was the beta I would say.
However.. I can add those methods and put up a release here until I accumulate enough to warrant another release and make the new functions a new inherited interface.
I will probably release the source to sourceforge at some point, Ive done a couple tricks with COM to get it to work in the unusual environment of a COM server implemented in a extension DLL of an .exe not intended to be one. And it'd be good to get a few people to look it over. But it will require some tidying up first.
You can use id3com to access ID3 tags. Take a look at the sendto_id3 export. example. Finding a copy of ID3com takes a bit digging though. I think its released as part of id3lib in source form. I dont think Id want id3 support in AW, its meant to be an interface to Winamp, and nothing more. Itd be like adding filesystem support to a calculator interface or something. To me, it makes more sense to use external 3rd party libraries to do external 3rd party stuff.