What's wrong with PAD files

There are quite a lot of things that are just simply wrong in the IT industry nowadays, I have already discussed the case of the Google Adwords, let’s move to the subject of PAD files.

PAD stands for Portable Application Description, it’s an XML format designed by the shareware industry to facilitate the submission of software products to software directories. The idea is pretty simple and pretty nice. As a software manufacturer, you create a PAD file for each one of your products; then you publish this PAD file directly on your website. For example, when Lokad did release its first open source product named Lokad Sales Forecasting for ASP.Net, I have created and submitted a PAD file for this application.

Submitting through cut-and-paste

Before PAD, you were just manually submitting your product description to every software directory of the web. Now with PAD, you’re still submitting your product description to every single software directory on the web; but the submit operation is now (usually) restricted to a single operation: cut-and-pasting the URL of your PAD file. The support for PAD among the shareware/freeware distributor industry is really impressive. I would guess that over 95% of the freeware / shareware industry now supports PAD files.

But the only thing really impressive about PAD is its absolute lack of design.

When the XML design makes no sense

As a software producer, you don’t need to manually generate your PAD file, you got a free editor (www.padgen.org) for that. Yet, I don’t think I have ever seen an XML schema that is so massively adopted while being so poorly designed.

They are so many issues with PAD that it’s actually hard to even summarize the topic. Following a quasi-random order, the main PAD issues would be

Note that all those suggestions would have made PAD easier to document, to produce and to consume.

Then some high-level criticisms could also be made

Summary: PAD has been designed by junior high kids (probably)

Based on the previous elements, we could say that the PAD authors had no clue about

Still, I think that a Portable Application Description is based on a good idea, but it would really need to be re-designed from scratch.

Reader Comments (3)

I use PAD files all of the time in conjunction with Shareware Tracker www.accusolve.biz/strack.html to submit shareware for clients. I agree there are a few problems with PAD files but in general, it is a great tool. I have defended a few of your claims below.

  1. The reason for having to specify your program size in bytes, kb and Mb is to cater for each different site. One site may want kb and one might want mb. If you are using free PADGen, it will automatically fill all of those file size fields for you. All you have to do is click on the file and it works it all out.
  2. You can include things like DirectX or .NET in the System Requirements field. No reason why you can’t.
  3. Most shareware sites do not support HTML in their descriptions. You can include carriage returns though to make it readable.
  4. State_Province applies to many other places other than the US. I am in Australia and we have states too.
  5. Some sites will only pull the primary download URL, others will pull additional download URLs. You need to include each of these separately. The additional download URLs are for mirror URLs which can be useful if the primary download URL is not working for whatever reason. (the naming of the fields is a bit silly I agree).
  6. Same for the screenshot URL. Most sites only allow one screenshot URL. I have been submitting shareware since before PAD ( www.softwaresubmit.com ) and I am a big PAD fan because it makes my job so much easier. Having said that, there are a few things which could be improved, but I guess it is a case of not being able to cater for everybody. (Please note PADGen 3 has just been released see www.asp-shareware.org/pad/ ). March 12, 2007 | Eve Sheridan

Thanks to challenge my criticisms. Yes, I am also a fan of the PAD concept, it does indeed makes my life easier too; but it’s really a pity to have such a good idea so poorly implemented. Taking your points

  1. I understand their motivations to ask for bytes, kB and MB. Yet, standardization precisely consists in making choices. Here is a clear example of non-choice.
  2. Yes, a system requirements fields exists; but it’s plain text. It does not add much value compared to the software description itself. Also, please note that stuff like DirectX won’t have the same name in Russian or in Japanese (again PAD is failing at internationalization)
  3. Never define a standard on the lowest common denominator within an industry, otherwise you end-up with drastic limitations. Stripping HTML tags out an HTML document is super-easy anyway. Thus, there is no reason not to allow HTML.
  4. OK, U.S.A. + Canada + Australia haves states (plus a couple of other countries probably); but most of the planet does not (ex: Italy, Russia, France, China, Japan, India, …).
  5. and 6. You miss my point. Several download URLs is a good idea. The problem is the implementation. Clearly here, an XML list should have been used. Same remark for the screenshot URLs.March 12, 2007 | joannes