Hi Marco,
On 15.07.2011 11:32, Marco Gaiarin wrote:
+ WSH, as stated in this list, have poor performance and limited
features when downloading
This is absolutely clear. That's also a reason why I do not really support the
<download /> tag in particular. I think it's just a legacy feature for very
basic download functionality. From my point of view most people would be better
off by using wget and similar tools.
+ WSH, as stated again here, have no hash function, any hash algorithm
have to be implemented in pure WSH or relay on an external script
Sure, that's why I don't think using the an md5 attribute in <download /> makes
much sense. As this would be either ignored in default case (pure WPKG
deployment without wget/md5sum). Up to now all the features of WPKG are
available by the default wpkg.js without the strict requirement for external tools.
So seems reasonable to, optionally, relay on an external script; seems
reasonable, because we can relay on an external script, to add the
'md5' field to<download /> tag, that the internal WSH downloaded
ignore but can be passed, optionally, to the external script.
As said above some features discussed in this thread would then require
additional tools (these tools would then not be optional again). So use of any
of these flags would break the package if the tools it relies on are not available.
Moreover such a hardcoded implementation would add a dependency to SPECIFIC
download/md5 tools like wget and md5sum. Alternative tools cannot be easily used
as the interface might be different. For example one might like to use sha1
checksumming or prefers an md5 sum tool which is faster but prints the output in
slightly different format etc.
You are right, we can just use existing<install /> and<update />
tags to do so, but the<download /> tag just exist, and i think is
more cleaner to use it.
Yes it might be more "clean" but using commands is much more flexible and allows
you to use any tool which best fits your environment (and not just one which is
chosen by WPKG team and enforces you to use this one).
So for me there would be only one compromise we could potentially think about:
Ship WPKG with a download-helper script.
E.g. ./tools/download/wpgk-downloader.cmd
This script accepts a clearly defined list of parameters like:
- Download source URL
- Download target folder
- MD5 sum in pre-defined encoding (optional)
- SH1 sum in pre-defined encoding (optional)
The script could then decide on some internal logic what to download and whether
the download was successful or not and then return with pre-defined exit status.
E.g.
0 all success, download finished, checksum OK.
1 download failed
2 any checksum failed (md5 or sha1)
However I still think it might be easier to provide such an optional script to
be used in commands rather than called from download nodes in package.xml. The
reason is simply that I see that commands would already support any number of
parameters, using environment variables etc. while using a strict download tag
structure always limits to certain features. So if later sha2 support or any
other special solution is required, then it would requiring to adapt wpkg.js
code. Using commands will work no matter which parameters might be added later.
[ Indeed, this have nothing to do with my ''server side download'' script,
using the global /noDownlaod switch on wpkg.js.
Clearly, also my script can be easily extended to use md5 hashes... ]
Sure, and even when using commands to download files it could be globally
disabled by simply supporting an environment variable NO_DOWNLOAD which makes
the script to skip its task and exit with code 0 instead (or alternatively still
verifying the checksums).
br,
Rainer
-------------------------------------------------------------------------
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
_______________________________________________
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users
