Hi, mscdex wrote: > What about implementing some sort of an "event-hook notification" > functionality where wpkg.js could call functions located in separate JS > file(s) (if available), so that custom solutions could be used. For > example, when wpkg.js detects that changes (whether installation, > upgrades, or removal) need to be made to the system, it could call the > appropriate pre-determined function in the external JS file. This > external JS function could then perform any kind of action, including > using a custom message solution to let the user know what's going on. If > none of these "event hook" external JS files are found or the callback > functions themselves are not found, then wpkg.js would just continue on > as normal.
Something which seems to be ignored quite often is that wpkg.js is based on JScript which is very limited and even based on an implementation by Microsoft which includes quite a lot of bugs which need special treatment or work-around. Another reason not to put too much into the "core" wpkg.js is the fact that each new feature or "extension point" increases testing effort. The result wil be that the code gets unmaintainable and each change can easily break something unintentionally. I've experienced exactly this with many applications I have been in touch with. The only way to prevent this is to keep the requirements slim. At the moment WPKG has some interfaces which can help doing similar things. On one side applications can "wrap" wpkg.js execution and track its actions (e.g. by parsing the output when using /sendStatus). In some cases even using a package definition provides an interface. For example a package which is executed at the beginning can of course call any program (e.g. one which deals with logon delay). It's also possible to execute packages only if there was a change done to the system so such a package could be used to call any application/interface you like to (external JS/exe/whatever). The user notification feature was never meant to be a generic interface. It was rather designed to send some "heartbeat" to the user. If somebody would like to call any non-officially supported notification application they might be added to the notifyUserStart(), notifyUserStop() and/or notifyUserFail() functions. As soon as we have a tool available which needs to be called by this functions I might re-think about such an interface like checking for <wpkg-root>\tools\notify[Start|Stop|Fail].cmd and execute it if it exists. But until then this would just add the risk of increased failure rate at customer site. With such scripts we might encounter even more failures due to the well-known broken STDOUT/STDERR flusing in WSH. So let's discuss about such interfaces again as soon as we have some toolset which requires it. The current WPKG client implementation does not rely on such interfaces. 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