First of all, I wanna say that I'm doing this for my own purposes only, so I believe I'm not violating rule #15. If I am, then please remove this thread.

I want to make a plugin that "handles" all filetypes. To be more accurate, it would to do a certain operation and then pass the input service function calls forward to the service that actually handles them. Kind of an intermediate layer between foobar and normal input services, mainly for filtering the metadata that gets written to or reloaded from files. (I really got tired of the way foobar's database works.) And it only needs to be done for local files (file://, unpack://).

As has been discussed here, it would perhaps require changing the component loading order, so that my plugin is able to register filetypes first. So how can I change this? Is it the same as the order of the dll files in the directory table? Or alphabetical order? And does loading order guarantee that input services are called in this same order?

Another option would be to use is_our_content_type(), which gets called for all services before any calls to test_filename(). But does foobar always call it, even when the content type is not defined and other situations like that?

Well, obviously I can test these things, but I still couldn't be 100% sure about foobar's internal behavior, so I thould I'd ask if anyone knows. Anyway, thanks.

Overriding other input services is not supported. The only solutions to implementing a tag filter is to use proxy files (like APL does) or to decorate the path (example: "file://C:\whatever.mp3" -> "tag-filter:|file://C:\whatever.mp3|"). The important point about the latter is to use both a prefix and a postfix, so that other inputs will not recognize the decorated path as their own no matter if they are checking for URL scheme or file extension. Of course, decorating the path breaks massrenamer and the like.

Is there any real technical reason for this besides the calling order? Anyway, it might not be "supported", but it seems to be working fine enough for me. I still haven't figured out that calling order thing, which depends on the dll filenames in a totally awkward way.. But I can still always override at least the filetypes I need, cause it somehow prioritizes those services that don't need a reader object.


Blah.. This solution ain't good enough. No advantages over the APL file method i've been using so far.

It might work well enough for you, but you are about to meet rule #15 when you try to release your "component".