On 2005-04-02 04:14:23 +0100 M. Uli Kusterer <[EMAIL PROTECTED]> wrote:
> At 3:57 Uhr +0200 02.04.2005, Frederico Muñoz wrote: >> [request for info on MacPad] > > Well, I thought the MacPAD stuff was BSDed or something, but I can't seem > to > find the license in the newest SDK anymore, so let me give you a general > overview, and provide you two example files from my own apps (i.e. with > permission): Thanks for you time to explain this. > > MacPAD files are XML Property List files (like Cocoa generates/accepts > them), containing information about a particular application. This includes a > download URL, current version number, bundle identifier, short and long > descriptions and release notes, as well as some other info. > XML prop lists is what I'm already using in Installer. > Not unlike an RSS feed, MacPAD files are stored on a web server somewhere > and kept current by the application developer. In every application package, > there is a MacPAD.url file (which is usually structured like a Windows > Internet Shortcut file), containing the URL of the MacPAD file for this > application. > Any idea why isn't this information contained as a key inside a plist? It would even work inside Info.plist. Just wondering because the Shortcut format is ugly. > Update checkers can now simply download the MacPAD file from that URL, > compare the version numbers and determine whether it's current, and then open > the product web site or download the file from the specified download URL. > Web sites can extract the MacPAD URL from the application and thus easily add > it to their list of files. > > Right now the official version mostly concerns itself with providing > information that is useful to software download sites such as > macshareware.net, but on Andreas' Wiki at furrysoft.de, there are some > proposed extensions to help installers, in particular support for > authentication so MacPAD can be used to download paid updates or updates that > require registration keys. > [example snipped] Well, I'm not overly concerned about supporting that usage (nothing against, again, priorities), but the rest of the fields seem sensible enough, plus the format in which the information comes is the best one to "parse". I'm not convinced about the Shortcut format, but nothing is perfect, maybe it is that way to make it simpler to parse outside of Cocoa (and GNUstep, since it natively supports that format). Now, outside of the paid updates/registration, the info in this files is not directly of interest to an Installer, except possibily the presence of a "Check for updates..." action. Something like Shovel, that works system wide, is probably the best way for a user to interact with the possible updates. Best regards, fsmunoz -- Frederico Muñoz
