I use that plugin for Miranda. It would be great if foobar had a similar plugin.

as a first step - it would be great to resurrect http://pelit.koillismaa.fi/plugins

Synthetic Soul you made a lot of valid points regarding the third party plugin site in the thread you posted.

<component>
        <dllname>foo_uie_explorer</dllname>
        <fullname>Explorer Panel</fullname>
        <description>A Columns UI panel showing an Explorer directory tree.</description>
        <author>JackieKu</author>
        <vermajor>1</vermajor>
        <verminor>04</verminor>
        <verrelease>6</verrelease>
        <verbuild></verbuild>
        <fooversion>0.9</fooversion>
        <upath>/components/foo_uie_explorer/1046unicode.zip</upath>
        <apath></apath>
        <uspath>/components/foo_uie_explorer/1046unicode-src.zip</uspath>
        <aspath></aspath>
</component>

This will probably never fly without some way to sort out the shoddily-developed components from the well-developed ones, and buggy releases from unbuggy releases.

Miranda's system's great for keeping components up to date, but it fails miserably at ensuring the stability of your IM client. Personally, one of the reasons I use fb2k is because I can rely on it, and as soon as a component sacrifices stability, it gets axed.

Well, not necessarily. You could make the component get a list of available plug-ins, it'd be fairly easy to build a file that lists all them all. I don't know any fancy stuff, but i could make something that worked right now -- an Access database to store the component information and an ASP page that builds a list of all the components in the database. The updater plug-in could just check that ASP page.

Component {
    -- same information that appears in Components section in preferences,
    -- so a tool can be used to extract that automatically 
    name = "Playlists tools",
    version = "1.5.3",
    description = "...",

    -- declares that this component replaces an older component,
    -- also used to track component name changes
    supersedes = "Utilities",

    -- name of the DLL that implements this component, a DLL can contain
    -- multiple components, for example "Playlist tools" and "Text tools" in foo_utils
    -- or the different archive format readers in foo_unpack.
    -- used to determine which DLL to download/update
    dllname = "foo_utils",

    -- foobar2000 version that this component has been designed for
    coreVersion = "0.9",

    -- used to determine if foobar2000 can load this component atall,
    -- reported by the component entrypoint function, so it can be
    -- extracted by the same tool that gets the name, version and description
    clientVersion = 71,

    -- a link to the download location of this file, either on the central repository
    -- or on the site of the component's author
    tracker = "http://...",
}

-- download declaration for a raw DLL file
Dll {
    -- which components are implemented in this Dll, strings are a concatenation
    -- of component name and version instead of DLL name to make matching
    -- more robust in the presence of multiple versions of the same component
    contains = {"Playlist tools|1.5.3", "Text tools|1.0"},

    -- download link
    download = "http://.../foo_utils.dll",
}

-- alternatively, an archive with a fixed internal layout can be used,
-- I propose one that is similar to the format i use for the "component archives" on my site
DllArchive {
    -- see comments for Dll, but an archive could contain more than one DLL
    contains =  {"Playlist tools|1.5.3", "Text tools|1.0"},

    -- download link
    download = "http://.../foo_utils-x.y.z.zip",
}

-- the final alternative for components that require special setup procedures
DllInstaller {
    -- see comments for Dll, but an installer could contain more than one DLL
    contains =  {"COM Automation Server|0.7"},

    -- download link
    download = "http://.../foo_comserver2-0.7-setup.exe",
}

This will probably never fly without some way to sort out the shoddily-developed components from the well-developed ones, and buggy releases from unbuggy releases.

A decent search would involve a description field and possibly some keywords.  I guess the component could also be used to search for other plugins, but is it really necessary?  I suppose the logical conclusion is a site with a web service for the component to query, but also an online search for those who prefer to use a browser, and view the full details of the results.  Users then have the choice of searching both ways.

Of course, the really neat thing about searching built into a foobar2000 component is that it could possibly download and install a component automatically, and save the user a few steps of clicking on a link, saving a zip, unzipping to the components dir, and restarting foobar2000.  Perhaps all that could be automated.

I suppose the logical conclusion is a site with a web service for the component to query