At 11:10 Uhr +0200 06.04.2005, Frederico Muñoz wrote:
> 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.
I think the point was that people can
double-click these files on MacOS X, no matter
what browser they're using, and they'll be opened
(IE and Safari both support them, and Mozilla
probably also does). Also, different from Apple's
own "URL Clippings" file format, Internet
Shortcut files are simply text files, while URL
clippings use the Mac resource fork. So, it was
simply the most common, most universal file
format for storing URLs at the time, I guess.
A fairly new development is also that support
for localized MacPAD files will be done by simply
having different MacPAD.url files in your
English.lproj, German.lproj etc. directories. Of
course, you could have those in the various
InfoPlist.strings files, but you might want to
auto-generate Info.plist and InfoPlist.strings
*based on* version information in a MacPAD file,
and then this would complicate things.
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".
There's no need for you to display information
you don't need. The reason I'm suggesting MacPAD
is that it already contains most of the info you
need, can be extended to include some more
(though of course you wouldn't want to store the
entire installer in there) and is already
available to Cocoa apps. So, it would aid
portability between platforms if the same things
were done the same way on both platforms. Not to
mention the whole point of MacPAD is to only have
to type in that info once.
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).
Well, making it easier to parse in this case
would be a pyrrhic victory, as you'd still have
to parse the MacPAD .plist itself. And if you
already have that code, it wouldn't be more work
to also parse .url files. Then again, a .url file
really isn't hard to parse.
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.
Well, I'd think that the version history,
product name and some of this info would be quite
handy. But yes, you mentioned update-checking, so
I thought I'd mention MacPAD, which is already
there and works. An Installer probably wouldn't
download the current MacPAD file, but maybe it
would be less work if the MacPAD file could be
embedded in an installer.
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
