[wpkg-users] Ideas for features.

[Rainer Meier]

Hi,

K.E.Jones at bton.ac.uk wrote:
>  I had a number of ideas for various features or code designs that might
> simplify some of the problems and make some good proposals. I'd have
> thought you'd have already got them on the timeline but as I've written
> a number of these bits into a custom version of the WPKG.JS already and
> have a few bits of other useful code I thought it might be useful!
> 
>  I wrote a huge message outlining those but I didn't want to hit the
> list with a huge message so I wonder if you'd find any of the following
> useful;

Let's see - probably we could try to sync-up some of the ideas after 
1.1.0 release.


>  1) A very basic sprintf equivalent for text output.
> 	 To simplify message formatting and maybe offer language support
> from an "language.XML" file? It could be very handy for the GUI :-)

WPKG output depends on the command line switches and the configuration. 
The log() function is the centralized logging and printing instance. The 
only thing which needs to be passed is the log message itself. Well, 
there is not much to format within these strings usually. At least I 
never missed sprintf or an equivalent function yet.

Language.xml might be helpful. However at the moment there are only a 
few messages to be localized. WPKG.js reads them from config.xml which 
is currently the _only_ file really needed on server side. In addition 
WPKG client does not read any of the files on server side (except 
invoking wpkg.js). I am not sure if it is within the strategy of WPKG 
client to support such a feature as localization on Windows applications 
is usually included within the application itself (included in the 
installer).

We might discuss about it. For WPKG it's just a matter of definition 
from where the translation are read. But I would prefer to keep the 
number of required configuration files at a minimum.


>  2) Extra <check> rules;
> 	 I have "Battery" checks; to detect laptops, "Disk Size/Free"
> checks; to prevent installs clogged up and failing from disk space
> problems, "RAM" checks; to stop installs failing because of
> pre-requisites.

Hmm, shouldn't the installer check these requirements (diskspace, 
memory...) and fail with an appropriate exit code if it does not meet 
the minimum requirements?

Checks are meant to check if an application is installed or not. If 
somebody would define a check like "memfree > 512MB" then this check 
would probably fail after next boot after the installation of some 
additional services. Thus triggering a check failure and making WPKG 
think the application is not installed.

In addition some of the checks might not be directly available to WPKG 
from the JScript API. I prefer to use stable APIs only.

Low level information like "battery status" might not be available 
within a clearly defined API. However there is already a check type 
called "execute" within WPKG 1.1.x - this allows you to trigger any 
external application which could do exactly these checks.

Probably some "helper tools" (which could be implemented in any 
programming language) could be developed and added to the repository in 
order to be included within the shipment. So administrators could 
execute these binaries right off the share as required. Instead of 
growing wpkg.js trying to implement every possible check in the world I 
prefer to outsource these very specific checks. Then they can be 
developed, debugged and maintained independently.



>  3) Tidy up ideas.
> 	Some of the standard WScript objects are created globally AND
> locally which is probably isn't necessary. A couple of processes can be
> re-factored into functions etc. Just general stuff I'd be happy to
> create patches for to make it easier to read the code and save some
> typing :-)

I know - most of them have been done on purpose (data encapsulation). 
Global variables have been avoided as much as possible. Probably there 
are some glitches I missed to change from 0.9 - but in general the only 
global variables should be listed within the header.

Probably we can discuss about cleanups for 1.2.x?


>  And last but not least;
> 
>  4) Two other alternatives to the Service/IE7/External command GUIs.
>       I've got a working .NET ActiveX/Com object that might do the job.
> I also have some experience with .HTAs that might be useful if you'd
> like to encapsulate the WPKG.JS with a built-in dialog (The script I've
> got is in VBScript so it might need a bit of time to convert it). It
> might help save some of the service wrangling Rainer's doing at the
> moment. If they work how I expect, it might also give Vista users a
> chance to have a rough GUI for installs too :-)

This sounds interesting - probably an enhancement to target for 1.2.x 
too? Well You say it's written in VBScript. My experience is that 
especially some things close to the system are not available in JScript 
(which are actually available to VBScript). But as I said, we could have 
a look at some ideas.
I try to find some time to finalize 1.1.x and make it stable in order to 
have a new base for completely new ideas and trials.



> PS: I'd be interested in honing up my newly acquired JScript skills
> (learnt from WPKG!) to start leveraging some of the object orientated
> behaviour of JS as well. It'd make a nice change to C# and VB.NET so if
> you need any small bits done or turned into object styled designs let me
> know!

Good to know.

Thanks for your support!

br,
Rainer