Maybe this is a bit off-topic, but would it not be a good idea to have some kind of a central repository for foobar components that keeps track of them, and their update status? It'd be slick to make it available right from foobar itself, and have it able to download them automatically.

Winamp almost has something like this... well, a central plugins page with automagically installing PIMP executables around every file.

I just find that all to often, if you want a plugin for foobar2000:
a) You don't know if it exists
b) You know it exists, but have a hell of a time finding it.

Most of the time, this can be done by scouring HA.org for a while, but it'd be nice to have something simpler, and this kind of a feature might attract more users to foobar2000 too.

Yeah, i was thinking about that earlier. I don't know if anybody here has ever used Miranda (an instant-messenger program that has a similar community and design philosophy to foobar), but if you've been keeping up with it recently you'll know about the Updater plug-in, which allows plug-in authors to register a URL (stored within the plug-in itself) that points to the latest version of the plug-in. You can then set Updater to run on start-up or once a day or whatever, and it'll compare the URL's version of the plug-in to the version of the one you have, and if yours is lower it'll download the new one.

I think foobar could definitely use a component like that, and i don't think it'd be difficult at all to implement, as long as the other component developers went along with it.

That's a great idea... and I love Miranda, BTW, but I haven't used it in a while now.

Also, given foobar2000 is for Windows, probably not too many people are familliar with this, but a Linux distro called Gentoo has a really neat feature called Portage, (invoked via the emerge command) which is derived from the BSD package management system".
Wikipedia Article: Portage (Software)

This feature makes Gentoo one of the most easy to maintain Linux distros (operating systems, even) there is, because it can automatically and easily keep itself up to date. Installing any program is done by simply running "emerge program_name", and it downloads, configures, and compiles everything automagically. It's wonderful.
You can also use portage to search through a list of available software packages (and there's a GUI utility to do this as well), so that if you wanted a graphics program, you could search for "graphics" and you'd see any program with that word in its title or description.

foobar2000 could definitely benefit by implementing a system like this... I'm sure that it could be added via a component, just like what lav-chan was saying about Miranda. I suppose that, unless the main developer of foobar wants to take this on with his main site (which would be the best), whoever makes a tool like this would also be responsible for maintaining the repository of foobar components, their descriptions, version numbers, release dates, and any other information that is relevant.

It would be nice, in any case, to have some standards for creating and releasing a component if the author has any intention of it being used by others.
By this, I mean things like:
-A standard URL for this on a specific website
-Presence in a searchable database of components
-(optional) an icon for the component
-A title of certain length
-A description of a certain length
-A release date
-A version number in a sensible format
-release notes and incremental version change notes
-links to relevant threads

If these things were present for all components, it would probably be trivial to make the kind of tool that lav-chan is talking about.


I think that it would help foobar2000 to grow and become more popular and useful for everyone.

Well the Updater plug-in i'm talking about doesn't really have a 'central repository'; it'll only update the plug-ins that you already have. There's another plug-in for Miranda that checks their site's file listing (which is more or less their 'central repository' even though it's ridiculously out-dated for most of the better plug-ins), but i've never used it.

I don't usually have any trouble finding the plug-ins, since it's not hard for me to keep up with the forum and stuff. I just sometimes can't keep track of all the new versions coming out all the time.

I second that, something like the updater in Miranda would be very usefull! Maybe something like that should be an official component delivered with foobar so that any 3rd party component could rely on it.

Count me in.

See this thread for a previous discussion along these lines.

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

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

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

So far this seems like a popular idea. But how does one get started?
To break down the logistical issues:

-All the developers have to agree on some kind of a system, and be willing to submit their new versions or new plugins.
-A central site needs to be actively maintained by somebody
-Some kind of a component is needed that will check the central site for updates, and allow searching for new plugins, perhaps. (I'd think this wouldn't be hard to develop, but I'm not volunteering right now, given my limited programming experience).

Am I forgetting something?

But indeed... foobar2000 really needs something up to date and more organized. It *is* the extensibility and modularity of foobar2000 that makes it so great, and it wouldn't be nearly as useful without the plugins. So if they are hard to find, that will be a factor stunting its growth.

If you're going to make your plug-in actually check a central area for components (even if you don't have them already), somebody wouldn't really even have to 'maintain' the site that much. Set it up, figure out some way developers can upload their files, let the updater component handle the rest. Use XML or something. The site wouldn't need to be visible/navigable from a Web browser or anything, so nobody would have to work on an interface (plus it'd save bandwidth).

great idea. i am on ha all the time, and i feel like i don't know what 50% of the plugins do. i am sure if i were aware of what most of these plugins did, i would benefit from them.

Thank you. I just think that there's no point re-inventing the wheel. The plugin site exists, and is a good place to start.

I just hope the webmaster for that site (anyone know who it is?) will get involved in this topic.

I would be quite happy to create a similar site but with registration and email alerts (as per my other posts). I think a foobar component interrogating a web service is a cool idea though. That said, that will only deal with components a user already has installed, and doesn't go anyway toward a user searching for and finding other components.

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.

Off the top of my head, the format for that page could go something like:



I dunno, i just woke up so i don't really want to think out how you would do Unicode vs ANSI or 0.8 vs 0.9 but you get the idea. And it doesn't need to be XML.

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. From what I know of the development team, they'd probably think along similar lines.

How it flies right now? The only difference I see is you have to jump between bunch of sites and threads just to get to know if there are any updates.



Miranda has tons of plugins, no wonder it has problems with stability. I do not think it will be better without Miranda Addons Database. I see the only way to increase MIM stability - to use less 3d party plugins.

I would gladly try to write a component doing that and I could do the php part too, but right now I don't have the time at all because of school works.. So if by June nobody has come up with anything, I'll start. By then I'm trying to keep this up to date with the available plugins for 0.9. It doesn't say when the last version has been released but I think nearly all of them are in the list.. that's a start.

Hmmm.. 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.

Anyway, I agree that it isn't a difficult technical excercise. What is required has been previously specified by myself and Supacon: all component developers need to be encouraged to use the system. The only way the system will really work is if all the components (or certainly all the important ones) are administered using it. Developers will need a login system to administer their components, and they will need to ensure that every new release is made available using the system, and that versions are documented accurately, descriptions are fitting, etc. The database/XML schema and programming are not difficult (I could not program the component, but it's hardly going to be Columns UI). The important bit is getting all the developers on board. This is where the current plugin site has a head start.

NB: the plugin site's author is amppa. He was active on this board around ten hours ago, so maybe we will get some input from him.

Here are my thoughts about what is required from the updating components point of view (informational fields for users may be left out). The format is a data-only subset of Lua 5.1, because it's less verbos than XML:

This allows searching for functionality and describes where that functionality is implemented, now for ways to describe how to install that functionality:

I'm not sure, if it is a good idea to have raw DLL downloads, but I included it for the sake of completeness.

The goal of this approach is to have as much of the component description file as possible generated from already existing data. What's still missing is tracking of intercomponent dependencies.

That seems like a legitimate concern, but perhaps misdirected. It made me think though, that this coherent system for distributing plugins could actually help to do exactly that... sort out the good plugins from the bad ones, and the stable from the unstable. I know that because of the 3rd party components, foobar2000 hasn't been 100% stable for me.

In this central site, there should be perhaps a wiki, or some way for users to add feedback and review the component, and then the average ratings could be another criteria that people could search by... (Winamp does something like this with their Plugins site). It would also provide a way for people to comment on possible stability issues and such. Right now, of course, that is what hydrogen audio is for, but it's pretty time consuming to weed through multiple forum threads to find a little bit of information that you are looking for.



I thought it would be neat to be able to search with a software GUI tool, kind of like Gentoo Linux's Portage GUI, but it would probably be enough simply to go to a web page where you could search through available plugins easily.

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.

Yeah, sure. Bear in mind, when I say
I mean just that. The data would be stored online, and searchable both by the component and a website search.

Your point about a component being able to automate the process is a good one.

One benefit of a web search, however, is upgrading. Why a desktop solution that may require upgrades, when you can just change a webpage. Deployment on the web is far easier.

That said, I'm definately not against the component being used to upgrade and search for new. I'm just saying "why not both?". The data needs to be online, why not an online interface?

Yeah, that certainly makes sense. It could probably have both interfaces without a lot of redundancy. I think that there could be a lot more functionality and information via a web page as well.

I'd support the idea of automatic updates.

Tried a low-level-discussion in this thread, as well.

(without a solution)


JD

Guys, I hope I'm not just revisiting a "let's-flog-the-dead-horse" scenario here.

But what if we use the HA Wiki as a central rep for components version and giving links there?

I appreaciate that there's a thread listing the known components; but this way, if OP is unavailable, the thread is not updated. Why not put the burden of update to the component maker?

My suggestion of using HA Wiki is detailed here. The beauty of my suggestion is several-fold:
1. No need for an admin to update the site; component-makers can update the site themselves.
2. No need for XML parser; the plugin merely have to download a single HTML page and parse it for DELIMITED TEXT only.

There's recent surge in demand for this kind of update notification, as seen here (my posting there) and also countless other threads.

It's probably worth pointing out the "conclusion" of another thread started around the same time as this one.

In essence amppa, the current plugins website admin, and Seldaek, a component developer, agreed to work on a 3rd party plugin update system for foobar. Posts can be viewed here.

Now, I realise that an update is overdue, and also that there are alternative methods. I just thought I should highlight that other plans are underfoot (?).

I am very keen to see a resolve in place, and don't overly care who does it or how it works; however I am concerned about a betamax/VHS situation, or simply component developers becoming confused as they are forced to update numerous different systems when releasing a new version.

I wish we could merge all these threads, get some key players interacting, and get a solid plan in place so we can drop this topic and move on.

What do you ppl think about RSS/Atom then? The official 3rd party plugins site just need to be alive and with RSS/Atom feature (so you can get to know if there's new plugins out there) I think is good enough for me. A updater plugin (it's only for update) that use that news feed would be a great idea. About what Seldaek post here about RSS, I don't know how will he impliment the component but if he have to download the list of all component at once then it will even waste more bandwidth than RSS with conditional GET, it would be even save more bandwidth if there's gzip/deflate encoding.

Maybe you should look at how Synaptic(s) Package Manager works, since that's the greatest thing since sliced bread. It's for Linux, and I'm sure it's for Ubuntu to install and update plugins. It works brilliantly, it finds dependancies (No more hell) and allows you to search. If works automagicaly as well.

Really, just having my plugins and foobar itself update to the newest brand spanking version would be awesome. -Cough- play_count.

This page exists ( http://wiki.hydrogenaudio.org/index.php?ti...:Components_0.9 ), but doesn't contain version numbers or release dates. The wiki is ideal for so many things in the fb2k world but apparently isn't referenced very often.

Personally I use this page to keep up with components:
http://www.hydrogenaudio.org/forums/index....showtopic=42730

Seldaek is a hero for maintaining it (although it would probably be best to redirect his efforts to the wiki).

IMO, we have to separate between "A complete list of all fb2k plugins under the sun and their uses" with a mere page listing "All known fb2k plugins and their latest version".

The first one is good for those who want to extend their fb2k. But for those who are already content with the plugins they have now, the latter page will be of much greater use, i.e. they know when to update.

I appreciate Seldaek's thread, unfortunately such a thread is heavily dependent on Seldaek to keep updating it. So I have to second topdownjimmy there, for Seldaek to shift whatever he's making into a wiki.

Heck, *I*will* create one wiki page, if you all agree, just to start implementing this. Please someone indicate his/her objection to this before I start making such a page. I will give you... oh, until Friday. Then I will dump Seldaek's OP into that page. I will not use XML, but will use the format I suggested.

Sounds good. I just hope the wiki page is heavily advertised, preferably by a sticky thread in the 3rd Party Plugins forum (the wiki in general should be more heavily advertised in my opinion).

I already mentioned in another thread a plugin for Miranda called Updater. I think you might have a look at it to get some inspiration.

Since school only starts next week and I was bored, I felt it was time to give a litlle push to foo_update development. So I started here what i think should be a good tool for developpers, a database that provides basic information based on what pepoluan suggested such as module name, version, build date and url to download site.
Dunno if it will be useful or not, but I had nothing better to do anyway

eejadx,

Thank you very much for taking the time to do this. TERRIFIC!

I renamed the wiki page, since "Central Repository" is too ambiguous for my taste. While the effort by eejadx is appreciable, I am doubtful regarding the long term usefulness of the wiki page, mainly because the table in its current form is quite cumbersome to update.

Please, let's bring the discussion of this wiki page to the talk page.

Gee... eejadx you beat me to it.

I don't think it should use a table. It's meant to be easily machine-parseable and human-maintained. No need for cosmetics.

So, I completely replaced eejadx pagedef with mine, just to not clutter it (remember, we can still revert to older version using history). My version should be simpler to update and parse. See the latest version here. To understand my point about ease of parse, check out the HTML codes of the page. See that ## BEGIN 0.9.x REPOSITORY V1.0 ## stands on its own, followed nicely by lines of entries, using vertical bars as delimiters -- no danger of confusing with other signs, etc.

Now, the foo_update plugin...? I think we ought to develop further based on the concept of foo_version. That plugin already gathers the name of the .dll, the version number, and the release date. Heck, in fact I build my prototype page using the output of that plugin. So we have to add some procedures to download the URL to the wiki page, perform a parse-and-compare, and so on.

PS: The links are all bogus. Had planned to insert actual link, but since the page is already up, I don't have the time yet.

PPS: If the format of the repository (version 1.0) is agreed, then all we need to do is to go to the respective plugin pages and ask the plugin creator to edit the repository page according to the rules of that page.

PPPS: I am having trouble with same .dll's outputting two (or more) plugins, i.e.:

The version doesn't match, only the date match. Any ideas?
This question also gets asked (and partially answered by me) in the talk page for the Component Repository

Okay, a great big thank you and high-five to Eejadx...

Ladies and gentlemen, with great pleasure we announce:

The foobar2000 Component Repository has gone ONLINE.

Click here to see.

Alright, now some guides:

For parser-maker
The parser may be a plugin, or a standalone utility. There are advantages of both.

• Do a scan of installed plugins a la foo_version; grab at least the .dll's name, version, and release date; sort it internally by .dll name
• Download this link: <a href="http://wiki.hydrogenaudio.org/index.php?ti...nent_Repository" target="_blank">http://wiki.hydrogenaudio.org/index.php?ti...nent_Repository</a>
• Parse the downloaded HTML until you find ## BEGIN 0.9.x REPOSITORY V1.0 ## or ## BEGIN 0.8.3 REPOSITORY V1.0 ## for version 0.9.x and 0.8.3, respectively
• Parse for two vertical bars; the dll name follows
• Parse for another vertical bar, the version follows
• Parse for yet another vertical bar, the date follows
• There are possible 4 kinds of URL's provided, gather whatever URL exists, and offers them to the foobar2000 user
• To handle the case where a .dll provides multi-plugin functionality with unmatched version numbers, do a comparison based on date
• Keep parsing until you run into ## END 0.9.x REPOSITORY V1.0 ## or ## END 0.8.3 REPOSITORY V1.0 ##

For plugin-makers

• Whenever you release a new build, update the repository page
• If you do not have update-rights to HA's wiki, check this thread.

For others

• Whenever you see your favorite plugin updated, either remind the maker to update the repository page... or update it yourself (if you have the update-rights; see above)

>> To-Do <<
Anyone can participate here!!

• Populate the 0.8.3 repository
• Write the foo_update plugins for 0.9.x and 0.8.3
• Maintain the repository page

>> To-Not-Do <<

• Convert the page into XML
• Beautify the REPOSITORY section
• Detail the descriptions

Your above post should be stickied somewhere with the title "Component Guidlines" or something similiar, otherwsie it's just going to be burried and forgotten.

Nice work! Much appreciated.

woah you rock!!!

You could go by the version of the actual DLL (version.xml in the resources)
Another alternative would be to use a cryptographic hash of the latest version.

Regardless, I'm not sure a wiki page is the best way to handle this. IMHO An intelligent server-side script that can be queried and provides output in several forms (XML for foo_update, HTML like the exising components archive for humans) would be better, easier to update, easier to parse and more flexible when new features are added later (XML is very extensible)

@ 'XML is very extensible'. Good job really...

NB: I agree with the idea of a web service.

Lol. I guess I meant it's easy to add new features without breaking backwards compatability, but I guess that's what XML is about, hence the name .
It's very appropriate for this sort of application.

While a web service has many advantages it has to be created and maintained.
I think it's a way better idea to start this on the wiki. That's easy to maintain and allready created.
If someone wants a webservice, everyone is free to write one - it could parse the wiki page and write to it.

But I'd like to request a change to the specs: There's no use in parsing the parsed page - why not just parce the code:
http://wiki.hydrogenaudio.org/index.php?ti...amp;action=edit
This way a parser is also safe against skin or source changes of the wiki.

I think the idea with a web service is that it would be fueled by a system where developers maintain the state of their own components.

It will be interesting to see how well the wiki page is kept up to date.

If you look at the source, and that is what a parser will do, the list that looks so nice to us humans is mixed with HTML tags, which will need to be stripped. E.g.:


If you look at the source of the edit page (how will the parser log in?) you get better results, but still not as intended:


I doubt this was the intention, but I may be missing the point.

Edit: As a resolve (as I don't want to just be negative here, I really do appreciate the effort) can I suggest placing the listing within PRE tags, and leaving out any wiki formatting, e.g.:

source = html source
source != wiki source

Enlighten me...

Edit: (... but bear in mind 1. My first example is the source taken from Firefox 2. The second example is the wiki code and 3. I've been a web developer for nine years)

I don't know if this has been discussed before, but http://pelit.koillismaa.fi/plugins/general.php already has almost everything needed, including allowing developers to update their own components. All it needs is some sort of XML/machine parseable output, and a foo_update plugin can be written easily.

I think the format should incoroporate some sort of changelog or release notes that the user is forced to view before installing the update (it opens in their face) in case the new version has important changes (like losing old settings), and there needs to be a standardised 'package' format for plugins, ie. a zip file with extension .fpk or something like that containing an xml file containing info on the contents of the package, specifying:

• Which files are to be placed where
• Optionally an executable to run (for complex installations)
• Some sort of digital signature to avoid corruption and malicious code

Public keys of all the developers contributing to the site could be offered by the webservice, after someone trustworthy (the site maintainer/admin) verifies that they are in fact who they say they are.
Perhaps foo_update would not even allow the user to install packages where the signature is invalid/unrecognised.

Just some ideas.

Check my posts #12 and #24 in this thread. I guess you could stick #41 and #44 in there as well.

I'd love to hear an update from amppa and Seldaek.

See my postings (all of them).

I try to make something that does not rely on just one person. Making a web service is good, programming-wise, but what if there's a new plugin, the admin of the web service is offline for some time, let's say, on a company-paid round-the-world trip for two?

The beauty of the wiki is that it is editable by all HA members.

Suppose another scenario, for instance, a popular plugin is no longer being maintained by its creator, and someone took over its source code. He/she fixes some bugs, post the version... but he/she can't update the repository?

As to 'which' source... why it's the HTML source of course. Like Synthetic Soul pointed out, how can the program log in to read the wiki code?

As to why I did not enclose the page in <pre> tags, it's so that the page is at least readable by human too. It's no big deal for programs to just strip out the tags and extract all needed information.

---

I just have been thinking... why must a plugin? A plugin can't effectively update other plugins, as the other plugins must be shutdown first... this means shutting down foobar, and then the updater plugin is also shut down.

Instead, I propose a standalone updater. This should be quite easy, IMO, it just scans all the foo_*.dll's in the component directory, gather the version number and date, download just one single HTML file from the repository, etc. etc. etc.

---

Edit: And if you want to create a web-service, go ahead. BUT IMPLEMENT SOMETHING, PLEASE! At least with this page the repository is already up... just waiting for the updater plugin/utility/thingamajig/whathaveyou/etc/etc/etc.

---

Edit2: And the second thing, wiki page is readable by humans. Web services are not. I do not use foobar2000 in my office, the only place I currently have Internet service. With a wiki page, I can just dump whatever plugins I have currently using foo_version, save the list to a text file, access the repository, and compare manually my plugin versions against those listed there. How am I to do that with a web service?

<rant>
Is it that hard maintaining a wiki page? Are we too enamored of technology that simple solutions are not acceptable?
</rant>

I was expecting a sytem like the current plugin site, where developers would log in and update it themselves. If they are on a world cruise they won't be programming, and the system is automated.

That user would register with the plugin site and post updates. You raise a good point, that the system would need to be able to transfer 'ownership' of a component.

Hmmm.. it's not a major deal, but trying to accommodate machines and humans may lead to difficulties. Machines want nice, uniform data to parse, and humans are prone to error and diversity.

This makes a lot of sense.

An acccomanying webpage to parse the output into a table, CSV, XML, whatever you wanted. A web service is just a data source, it will always need a parser/interface.

I guess it depends on your requirements.

I seem to be coming across as very negative, yet I am really just posting my opinion. If this solution is your ultimate solution then you go girl, that's fine by me. All I have ever done in the many posts I've made on this subject is to try to get people to think about what they do, so that we end up with a workable solution, and not five different solutions none of which work properly. I am not saying that this solution does not work properly, but it would not be my choice of execution. Just MHO. I don't expect it to stop the project in any way.

My solution of choice would have been something along the lines that amppa and Seldaek were discussing. Yet, that has not materialised, so this solution is a marked improvement.