Hi folks,
Decided to create a topic for the 3rd party components site for discussion regarding the site. Later this year the site will be 5 years old, so I guess it's about time.

What site, and why?
The site is for hosting information and files for third-party foobar2000 components. The basic idea is that component authors would register, add their own components, and keep the data up to date. The site supports so-called moderators, too - active users who help by adding new components and editing existing ones to keep the data valid.

In the last 30 days, the site has had ~25k visits from unique IP addresses and a total of over 466k pages/items accessed (counting all images etc. separately). So, there is continual activity even though some of the information is quite out of date.

Normal users can sign up and subscribe for component updates. Consequently, if that component gets updated, the user will be notified by e-mail. The interval of e-mails can be defined, so there won't be an onslaught of spam. Additionally, one can select to receive notifications from completely new components added to the site.

There was once talk about central repository that would support a component auto-updater. The component never arrived, but if someone would like to make one, the site will definitely support that. In fact, it's still generating applicable data files.

Discussion and the future of the site
Recently Fifoxtasy volunteered to update some of the components, there has been quite many updates (and improvement suggestions ) since then. However, there's too much to do for just a couple of active people (and people will predominantly update only the components they're using anyway), so it would naturally be best if component authors themselves would be active. I can't say if there is any way to attract developers, though, I guess they just have to find the service to be useful enough. A kind of "chicken or the egg" problem.

One thing that has crossed my mind every now and then - should the site have an easier domain name? I guess they don't cost that much, if I only came up with some remotely good one...

Some kind of a todo list of features that should be added sooner or later.

• Tell more clearly what are the advantages of registering (Fifoxtasy)
• Checkboxes for enabling/disabling component subscriptions, now one needs to re-add them (Fifoxtasy)
• Separate lists for newly created and recently updated components (Fifoxtasy)
• foobar2000 itself should get a section and its own entry, so that superseding could be marked, and people could subscribe to receive notifications when a new version of foobar is released (Fifoxtasy)
• A list of component update requests on the componen't page, so it would be easier for authors to address them (Fifoxtasy)
• A change for user pages so that it would tell more clearly who is the component author and who merely added it to the site
• Create RSS feed of new components/component updates? (kanak)
• Change the "update request" link's name (kanak)
• Group the update requests by component (kanak)
• Try if a wiki-style list of components would be good (Bachi-Bouzouk)
• Unify the escaping of component data
• Add the current version info directly to component description once there is a default download field

Recent updates:

• Add a new selection for selecting one link to be compatible with auto-updaters (2008-07-14)
• The components supersede one another instead of files superseding components (2008-07-14)
• If there's only one search result, jumps now straight to the component's details (Fifoxtasy, 2008-07-06)
• Separate the "locked" and "admin message" list (Fifoxtasy, 2008-07-06)
• A link to the component from the component info editing page (Fifoxtasy, 2008-07-06)
• Superseding is now shown more clearly, even if the component is locked (Fifoxtasy, 2008-07-01)
• Moderators can edit the locked status and component-specific admin notifications (2008-07-01)
• Moderators now get a list of locked components (2008-07-01)

Hi amppa

i'm glad you found the time is right to create a thread for your site.

you need to change the link on your main page to direct to this tread now.



i would say that one component simply supersedes another. it would be quite unlikely to happen. if let's say the new version brings those new features. who is going to use the old one? are we going to keep every old version? no we try to keep everything up to date. so i think it would be a lot less complicated and easier to manage, if a component either supersedes or doesn't.


a thing i'd like to say is that even though it is true what amppa says: it would be best if the component creators keep their components up to date on the site. i don't think ALL of them will ever do it, so there will always be a need for moderators.
right now i think there is even a great need for more moderators and i'd like to encourage the people to contribute to the site. it's not that much work - if you stumble upon a new version, you update that entry in the database. done, takes you a minute and you helped everybody else who uses that component. if they subscribed to it, they will get notifications - no need to periodically check for updates in 20 different threads for all the components you use. if one day that updater component will be developed, it will get even easier.

I agree really strongly with this one; I know that I personally have never been able to remember the address of the site, and had to either use bookmarks (when on my own computer) or google (when on a different computer). A more unorthodox domain would go a long way.

Another thought; maybe you could be linked through the official site?


Other Comments

• Display latest version of component when viewing its description. This would make updating the entries much easier. (I realize that the version is shown when "download" is clicked, but i think making it more obvious will help.
• In a similar note, would it help to have a "latest version (Beta)" type description so we can link to beta/alpha versions? This would be particularly for foo_dop and Column UI whose alphas/betas are really stable, but have an older 'stable' version linked too.
• Allow filtering by 0.9.5... there is a sizable number of plugins that don't work well with 0.9.5.x onwards.
• RSS feed: with the newly added plugins

Finally, I'd like to be a moderator, if possible.

EDIT: added comment about displaying latest version, and beta version.

It would be nice if all 3rd party developers used this site. Its hard to track down some of the less common plugins sometimes. If it was updated i could see it being an excellent resource

components.foobar2000.org if peter and his team agrees to use that domain...

if not maybe something like:
www.foo_components/fooponents/fooplugins/fooplugs/foobar2000-components....
:/ i dunno, can't come up with the perfect name either...

you're right, just what i was thinking. whatever domain name is chosen, it would be great to have a link from the official site to the 3rd party components site.


i didn't add the 0.2 (stable) link to columns UI because on musicmusic's site he says
but it would be possible of course: see Scheduler for example, you got download links to two different versions. the version is displayed right next to the download link.

good job on your updates kanak!

Hi

First of all, I'm really very happy to see that your website is alive again.

For me, as you said, you have to attract first the plugin developers. And to attract them, there is no other way than giving them "services".

A few weeks ago, I thought abut a similar website (as I thought your website was abandoned) I started to create a mindmap to know what information could be interesting:
http://eolindel.free.fr/images/plugindb/Plugin%20DB.html (a little part is in french, but it is quite understandable I think)
Quite a lot of information is listed there and obviously it would lack for a lot of plugins, but each information is relevant. It would turn your website into a little sourceforge platform for fobar2000. But it would also require a lot of time to create such a thing , which you probably don't have or want to spend on this.
On the other hand, developers would see that it's also in their interest to use such a platform to make their plugins popular.. As for the moment, it's quite a jungle and nearly all developers let away the documentation/presentation part away..

To me, the website would also require a little relifting : You always are on a very long page listing components with a quite extended description while on this page:
http://wiki.hydrogenaudio.org/index.php?ti...:Components_0.9 the information is quite short and sufficient to describe the plugin and really less confusing than it is currently on your website.
For me, a table listing components with a small description as on the wiki would be enough. And then have a link on the plugin name to have the level of description that you already have.

I would also separate more clearly what is for 0.9 and other versions. (with sub websites) to less confuse visitors at the beginning, it makes things more difficult for the moment.

A lot of "I would" "It would be nice to" post, but the project is really interesting !! If you need more ideas etc.. I'm willing to detail some ideas or give other ones .

Good luck guys !!

P.S. BTW, I will point to your website on the latest version of my manual which I'm currently rebuilding. (and probably give to your website a nice place in the step by step tutorial to help newcomers)

A neat addition would be to have a plugin which would check the components on your computer and then show you links to whichever new components available. Great site, by the way.

Wow.. I used foobar for years and never saw this site before..

BTW..

@kanak

Direct download link for Channel spectrum panel and EL playlist doesn't work. (403 forbidden)

reminds me of good old times, when i learned how to use the title formatting strings. that site helped a lot. i still did not become an expert, though

You mean http://fb2k.org isn't easy enough for you guys?



Yes, that was a renegade domain name registry by yours truly... Might as well point it at the components site.

Thank you. I have some more feature requests

• Change the "Report Update Request" to something like "Report Entry Update" or something. I was going through the user reports, and a lot of them are along the lines of "PLEASE UPDATE THIS COMPONENT FOR 0.9".
• Speaking of user reports, would it be possible to add checkboxes or something to enable mass deletion of requests? Out of the 150 or so requests there, it looks like only 30-40 are actual reports, the rest are either requests for the developer or downright weird ones like "1".
• If it isn't too much to ask, grouping of user reports by components, or atleast, allowing us to view user reports when browsing components would also be great.

Hmm... once bachi has his guide complete, we could add a link to the component-specific guide on his page. It would definitely be helpful for the new users.



Thanks for the report. I've removed the links; you now need to go to the official site to get it.



Wow! Thank you so much. No more googling for me .

Hi amppa

I recently thought that it would be great to have an easy and fast way to update my foobar components.
I know your site but it felt always pretty outdated, i really, really hope it will become more popular as the primary source of foobar components.
Maybe i can contribute a bit...

I was taking a look at the data feed the site provides and thought i could look into making an updater application for foobar.
I said application because i'm not into foobar components and it would be much easier and faster for me to develop a stand alone application for that purpose.
Of course the app would be as interoperable and as "silenced" as possible. That means that there wouldn't be the need to launch the app separately or other major annoyances.
I don't think that having a stand alone app as updater would be an issue, but please correct me if i'm wrong.

In case that would be acceptable and interest you please feel free to contact me either here on the forums or by mail @ rain.net#gmail.com

Good luck with you project

awesome


amppa:
concerning the admin message and locked components
now on the user page components both locked and those containing a admin message are displayed in a list. i think you should create two separate lists, or maybe only locked components.
maybe we are misusing the admin message? take a look at them, we used them for all kinds of messages. see EL playlist for example. there are some components with messages like that. when should we use the admin comment? if it should be used for all kinds of info that don't really fit into the description, i think components with admin comments shouldn't be displayed in the banned components list.

In fact, some thing should be easier in a stand-alone application than they would be in a component. Just think of actually replacing component DLLs.

You're right foosion, but when i said "issue" i meant to the users. I know many who prefer such a function to be part of the actual software instead of having to deal with another piece of software.
Obviously i would try to make it as easy and as non-intrusive as possible.

as i don't have any programming skills, i have no idea what would be best to update the components, but i just wanted to say that it would be great if you could develop such a thing!
i think it wouldn't really matter to a user if it was an external app, if it would be easy to set up with foo_run. but i might say that maybe a component would be more "fool proof", but hey, this is foobar2000 not windows media player! foobar users will manage

Yeah, I guess it would be the most convenient way. Maybe I'll change it to work like this, it's always possible to change back if the new way is not so good.


I listed also the components that have an admin message because I thought it would mostly be used to add warnings that a component may cause unstability. I think your way to use the field is fine, though. Perhaps I'll split the list to two parts, "locked" and "not locked but contains a message".

nice!

great!

I'd love an RSS feed for the recently changed components page...

Exactly what i was thinking Fifoxtasy.
But i wouldn't try to make some sort of interface with foo_run or such things.
This would be an application on it's own, my idea is something like this:

Single executable file to be placed in you foobar directory which acts like a "launcher". That means instead of launching foobar you launch that exe which then checkes you components and foobar core exe for newer stuff online.

When you launch said application you don't notice anything, foobar will be launched by this app while it checks your components. This way, if no new components are available you don't have to wait for the updater to finish checking and can start listening music right away. In case the updater finds new stuff several different things could be possible:

1 - You get notified.
2 - Components are downloaded automatically (you don't necessarily see this, just if you wish to).
3 - If you are paranoid you can choose to download them manually and let the software point you where the files are located.

If you choose to automatically install components foobar needs to be closed, again:

1 - This could happen automatically (restarting foobar automatically afterward).
2 - Or at next foobar startup (so you can finish to listen to your songs).

The only thing that would be visible would be the notification of updated components once in a while. No need to setup anything, by default updater would check once a day for updates, and these kind of things could be configured through an options screen.

The only thing that could be "difficult" for the end user would be setting up the shortcut, but even that could be managed with an installer

1. I didn't quite understand what should be shown. The component's version number? On the pages that show lists of components?
2. Usually the alpha/beta versions are ment for testing purposes. I think that the current functionality is ok here: on most components, most people will prefer the stable, so its version number is shown, but link to beta can be added, too.
3. This might be a bit problematic: most of the components that work in 0.9 work in 0.9.5, too. How they should be filtered?
4. Canar seemed to wish for this also, and I think it was on the initial wishlist some years ago, it just never got implemented. I'll add it to the todo list. I hope that you are patient with the updates, time seems to be quite limited these days, so some features may take some time to add..

1. You're right, the current text is not very good. It was even worse initially and I changed it to the current one, but obviously it still wasn't good enough
2. Well, the reports have been cumulating for some time now, I think. Once (or if..) the list gets processed, the feature would hopefully be a bit useless, so I think it would be better for me to go through the list than add the feature
3. Yes, grouping should definitely be done. It's currently sorted by request date, which isn't that useful.

The site has never died, may have been just a bit quiet every now and then You're right, I'm kind of hoping that modest changes to the current functionality are enough - as I just mentioned, there's not that much time as there used to be. Or maybe I'm just using it in the wrong way. Your idea of more services is interesting one, but I don't think I'm quite up to making that large changes. Furthermore, many plugins are pretty simple ones when compared to some Sourceforge projects, so the benefit over the current discussion forum way might be limited for most of the components.

The list of plugins in the wiki style could surely be done. Either I could add a field for a short description, or it could just use the first sentence of the plugin's current description. Or maybe both: a possibility to add the short one, and if there isn't one, the first sentence would be taken.

The sub-sites for different versions may be a good idea, too. I'll have to think about that if I make that compact list of components. I guess the filtering is suboptimal: after all, users are looking components for their current foobar version, so there isn't any need to list the wrong versions even if they are minimized as they are now.

Thanks for comments!

maybe you could do both. so you can run it as a launcher or through foo_run. maybe people don't want to check every time they launch foobar. if that's not too complicated of course.

you might want to take a look at miranda's updater plug-in. it works very well, and has to do about the same job. i think you can get the source code as well if that helps(?). it also let's you choose whether to use beta versions or not - might be a good idea as well.
---

you could handle it like a new foobar version. like 0.7, 0.8, 0.9, 0.9.5
but the 0.9.5 filter would have to include all 0.9 entries as well.
but then we would have to change all the components which aren't compatible with 0.9.5, and maybe keep old version links for 0.9 users. i don't think this would be worth the hassle. users who upgrade their components also upgrade their foobar don't they? except for panels UI users. but is all that work worth it for a couple of users of a banned component? i don't think so
---

i don't quite get the advantage of sub-sites over filtering. i think filtering is better, because you can list ALL versions or just the version you need. you set the filter to the version you want, done, you will now only see components that are available for your version. what's the problem?
---

Edit:
@r41n: what about the files, would they need to be on amppa's server or are direct links to servers ok? what about archives? would you need the .dll or are the rar, zip, 7z files that developers use ok?
---
sorry panels UI is not banned, but it is disrecommended and listed as a potential troublemaker and have a look at this thread.

Sure, I'm all for it! if you're starting the project, I think it's ok to discuss the details in the forums, so other people can step in if bad ideas are introduced

A couple of things that comes first to mind:

• The data file is just an example. I can make it any other format, too, whatever is the most suitable format for you.
• There's also a compressed version of the file (.zip), I hope it's ok to use it - would reduce unnecessary bandwidth eating. I can provide some other compressed format, too, if you prefer something else.
• The updates are hopefully checked in some random way, so that the server won't get a zillion hits at once when all instances check the updates at a specific time. I think you had a pretty good idea already, checking every now and then when people launch their players. IMHO, there's no reason to check every day, but on the other hand, some other probably prefer it that way.
• There's the trust issue: some will be quite wary to download updates automatically, even if the result is the same as when taking them manually. Maybe some way to check the updates first or something. I don't know if there is anything that can be done in the server side to bring more trust, just tell if you have any ideas.

Fifoxtasy maybe i wasn't clear enough...
The app would run every time you launch foobar through it, but that doesn't mean it actually checks every time. The app launches foobar for you so that you don't need to launch two separated applications (or remember yourself to check for updates).
It will check for updates every 24 hours or maybe more(you can change that), so that means that if you might launch foobar several times during the day the app will check for updates only once in a while (just like any other update software).
So usually it would shutdown right after starting foobar for you. It would be there just for 1 second, probably less. Only once in a while (when it's time to check for updates) the app would stay running longer to gather info on available updates.
Practically that means you will have to deal with that app only once a day or less.


Hi amppa, i'm happy you mentioned it, the data file format seems alright, but it would be nice to see what other data formats you could provide, like xml for example? Just to see which would be the easiest to parse

Zip compression is great, as long as it is standard zip i'm fine. Are the components by chance all compressed using standard zip too? I really would like to avoid the need for several compression libraries (for auto-installation updates).

Trust is an important matter which we should discuss better in a second moment.
If i understand how your website works, pretty much everyone who is registered can update a component, right? On the other hand being an authors doesn't make you necessarily trustworthy...
I could make it so that the user can choose which components are automatically updated and which not, but i'm not sure if that will help.
Anyway, as i sad before, i will implement auto and manual download right from the start so ppl can choose to disable autoupdating and just get notified.

I thought about the update period only briefly, first i thought once a day would be ok, but after thinking about it a bit i figure it's too much. I'm rather new to the foobar community, but concerning 3rd party components i feel like they don't get updated that often, i might be wrong though.
But i don't think it's urgent to talk about update periods right now, these details can be changed easily later anyway.

I'l start looking into it right now

nice!
---

Since i became a moderator (2 weeks ago) we cleared about 200 reports! now there are only less than a 100 to go sweet

Zip and 7z are by far the most popular. In fact, I don't think i've ever seen any other compression format being used.

How stupid of me, i didn't think about this at all.
When someone downloads from amppa's website those download links are redirects to some other website (hosted by the individual component author), right?

If so that could be a problem for the autoinstaller feature, if an author doesn't use a compatible compression format.

Now, i don't think that anyone really cares, but while i was trying to parse the current foo2k version info from foobar2000.org i retrieved version 0.9.5.4...and i was like "wtf, must be an error in the code..." after a few secs i realized they released a new version

Does this already qualify my piece of code as some sort of updater software? lol

Since you mentioned the application wouldn't check for updates unless it met the user's update check interval settings anyways, might it not be a good idea to just have the updater not worry about launching foobar?

Why not have it just be an updater they can run when they want to check for updates of their components/foobar install?

That way you don't have to worry about adding in options for how often they want to check for updates, etc. Those kinds of options really only make sense if the program is going to be running all the time (for example, if it were within the actual foobar program).

Just a thought.

These two problems are the reason it might make sense to start having the plugin site host the files, much like other application plugin sites.

amppa, have you given this any thought? I can understand if it might be too resource intensive.

Ironically foo_version would be perfect for this, as shown by Miranda's own equivalent from which I believe it was ripped off...

I'd like to report a bug:
The "Recently changed components" lists components of random date, rather than the most recently changed ones.

That's right, the links are redirects. The site can already host files, but it's up to the user editing the component if he chooses to add a link to the author's site or upload the files to the 3rd party site.

I guess I can make XML data files, too. Also, I could try to interpret the file type (from the link filename extension) and add it to the data file, so it would be easier for an updater program to see if it supports the format or not.


The list shows two dates, creation and modification date. The list is sorted by the modification date.

Fuller2.0 i already thought about that and i probably will make it so that it will be up to the user to choose if he wants to check for updates manually or not (launch the updater manually or have it launch foobar).
Personally i think it makes way more sens to have an update software check on a regular basis for updates.
There are some softwares that have some processes running in the background all the time checking for updates and i think that's pretty annoying, so i figure having an updater that starts your software might bother some folks.

amppa, i thought you already had the possibility to provide another data format, but if i got you right you need to do quite some work to get a xml data feed.
If so, don't bother, the actual data feed is just fine, i thought you had and easy and fast way to switch data format, that's why i asked

Concerning the file compression format i think to get an autoupdater working there would be the need for some sort of standard file format. While i see that hosting files can become resource intensive i also guess it's the only way to enforce some sort of standard.
But for now i think it's fine the way it is, autoupdating will need some major things changed as already discussed (trust, compression format) and that won't happen in the near future

Yes, there are no other formats currently available, I'd have to create one, and it would of course require some work. If the current one is good, all the better. I don't think anyone has actually tried to parse it yet, so it is possible that it's not unambiguous or something, just ask if there are any problems. The zipped data file has been there all along, http://pelit.koillismaa.fi/plugins/data/repository.zip.

Of course, it would be best if an autoupdater would be able to read multiple compression formats. For example, I think quite many formats have command line decoders that could be used. Hosting all the files is not a very good solution: the amount of transferred data could be a problem (though I doubt that not very soon), but a bigger thing is that many authors may prefer to have the download links to point to their own sites. The reasons may vary - maybe some want to keep more control, maybe some just don't like the idea of using a central site. What ever the reasons, the actual authors of course have the final word.

Shouldn't be a problem parsing that data feed

I hoped to keep the app compact and simple in a single exe, but supporting several compression formats would be optimal.

Problem is that many compressors can't be redistributed freely. In other words the users would need to go download and install those additional exes (just like you would do with codecs for the foobar ripping feature).

amppa, have component authors mentioned they don't like the idea of putting their files and not linking to them on their own servers?

It seems like there are a couple fundamental differences between the component site as-is and the way other component sites work (like Mozilla's Add-ons site, and the Miranda IM site).

These other sites seem to require the component author be the one who update his/her own work and keep the listing in order, as well as require that all files be uploaded to the component site.

These options seem to keep things running fairly smoothly.

If an author wants their component listed, as one would assume they would, they have to take responsibility for it. They can still link back to their own pages, but the files and basic info are always available on the component site.

Such changes would also make the reliance on other people updating the listings less, and allow an updater like r41n's to work smoothly.

I assume you have considered these options, I just thought I'd throw that out there!

Indeed, it would be nice to achieve some sort of central place for components (addons) like the miranda community has.
I really don't see the point in keeping component on personal pages, if you release it on you personal site without access restrictions you probably want it to "spread" so it's just logical to go and put it up somewhere where users can find it easily.

amppa i took a look at your data feed and it seems to me there're some incoherent "tags", usually only in the "urls" subgroup.
I see all sorts of different ways to name the download URL.
It isn't a major issue, but it could easily become one depending how i choose to develop this updater.
I guess those "urls" tags are named by the ppl updating the component, right?
I don't see how else there could be so many different tag names..."Download link" is the most frequent, but there are some called "binary", "Multi-language download", "Direct Download" and so.
At first glance that doesn't seem the case with the links to forum discussion threads or homepages (they all seem named "discussion" and "homepage").
Another similar issue is the version info, it seems that a few components just have "coreversion" tags (which i presume indicate the foobar version required) and miss the "version" tag.

Is there some way to fix this?
Maybe by moving the"coreversion", "version", "download link", "conversation link" and "homepage link" out of the "urls" subgroup, make them always present and avoid that these tags have random names? That would be perfect.
There still could be "personalized" URLs for each component in the "urls" subgroup, these then could be handled just like URLs the user can click in the updater.
For example the "Audio Authentency Detector" component needs a 3rd party software and has a custom download link in the "urls" subgroup that point to some "auCDtect (True Audio) Download" page.
The updater won't be able to handle that link automatically, but could show it to the user so in case he could go and check for updates if the component get's updated.
I hope i could explain my point

Another thing that comes to my mind is that it couldn't hurt to have a bit more control of what data is provided by ppl who update your site.
It would be good to force (without unnecessary brute force ) input of required data, like dllname, name, version, coreversion and all the data required to properly identify and confront version information of components.
This could prevent many catastrophic update failures on the long run.

I don't know of such wishes, but as long as it's not authors themselves who add the components, it should be taken into consideration. And, if we would allow only authors themselves to list the components, the current component list would be quite short. Maybe some more authors will become active if the updater program becomes widely used.


Yes, the links are named by the user who is updating the info. There are a couple of fixed links (homepage and discussion) - that's because these links are shown separately on the right hand side of the component description. If you want to check how the system currently works, you can create a new bogus component that clearly tells it's temporarily for testing purposes, and delete it once you've seen the functionality.

Of course, only one download link at a time should be allowed to be the so-called auto-updater compatible link, righ? In that case, I think it would be best to add a new drop-down field that lists all suitable links (uploaded files and "general links" that have component version and coreversion defined), and you could select only one of the list.

Name and foo_name are of course already required, so this change would mean that all the necessary info is present, right? This would mean that all components should be edited so that they have that default download link, but I think that's ok if it is necessary. Furthermore, this way we wouldn't have to enforce any naming standard for the links that the users add (which, I think, is good).

I think lots more authors would become involved if this updater program becomes a reality, and if they knew that they could control and manage their component profile on the add-on site by themselves. Perhaps someone should branch out to many of the developers and ask their opinion?



Why would enforcing naming standards be an issue? Wouldn't it allow for easier sorting and management of the add-on site? I'm just curious about that part.

I too think it's a good thing to let the users add custom named links if needed.
The only problem i can see is that multiple download links for a component, other than older version or so, can't be handled easily by the updater.

For example: if a component is provided in different languages and there is a download link for each language that could be a problem. While there could be ways to handle such a scenario i doubt it would be forth the trouble.

On the other hand if a component has a "current stable version" download link, a "beta download" link and download links to older versions that wouldn't be a problem at all.

As long as the latest release version of a component, the required foobar core version and the download link for exactly that version can be clearly identified in the data feed everything is fine.
I don't think there is need for a thing like a dedicated URL for the autoupdater on you site, as long as the primary download location is clear, as explained above, the current system should work out pretty well.

I have no way to predict what each user wants to link or upload, so I think it's better not to even try, if it isn't really needed.


My suggestion would mean that the updater would only have one field to look for the file (the one that is marked compatible, and there could be only one marked as such). If there is no compatible link, it would not even try to get the latest version. It wouldn't have to be dedicated just for the updater - on the component page, it could show as a normal download link, or it could be highlighted so that users would immediately find the link to the latest stable version. It would be quite much more straightforward only to have one possible link for the updater - if someone wants to use a beta version or some other language, I think that should be handled manually. So, I guess we agree here

Indeed, when a new component version is available the updater can display less "important" links related to that component directly to the user (if he\she wants to) so they won't be ignored.

If it isn't too much work it would be nice if you could put the downloadlink, version, and coreversion related to that link outside of the "urls" subcategory. As some sort of "main tags", together with name, dllname and so on. That could make it a bit easier to parse

BTW, i need to know if while generating that data feed your code escapes in some way the special characters in the value of the fields.
Example:

name="Audio Authentency Detector"

If someone names his component: fred's "beast" does that end with a data feed that contains the following name value?

name="fred's "beast""

Just a detail that i need to know, just in case

amppa, I guess I said that badly. Pretty much exactly what you described is what I meant. Have one set label for the latest compatible download so r41n or anyone can easily work with it.

Also, r41n's idea of grouping together the most important information really makes sense. The latest version download link seems like it should be separate from other links. What do you think about that?

Just to prevent misunderstandings, in the last posts i always referred to amppa's website data feed.
Though i agree that highlighting the main download link on you site, separating it from other related but less important links makes sense.


Never mind, i found a component entry that features exactly that

Canar was kind enough to let the site use his domain, http://www.fb2k.org - now it is working as a real domain, not only as a redirect. Should be a bit easier to remember

The formatting strings site is found at http://formatting.fb2k.org, even though it has been quite dead for several years now.

Awesome!

Amppa could you tell me how exactly your code escapes special characters like " if they are part of the value of a field in the data feed?
I could figure it out by myself, but if you could provide me the info it would probably be easier.
Thanks