[wpkg-users] Ideas for features.

[K.E.Jones at bton.ac.uk]

Hi,

 Time to squeeze in some re-thinks and thanks :-)

{Sorry about the wrapping, we're an MS-based shop and Outlook just sucks
at being internet friendly so I've had to hand-wrap most of this}

> -----Original Message-----
> From: Rainer Meier [mailto:r.meier at wpkg.org]
> Sent: 30 June 2008 22:48
> To: Jones Keith
> Cc: wpkg-users at lists.wpkg.org
> Subject: Re: [wpkg-users] Ideas for features.
>
> 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.
>

	I think that that can only be filed under the word "Groovy!" :-)

>
> >  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.

 I totally understand. As you say there's not much there to produce
templates for yet although maybe it might be useful to 'pretty print'
the debug info and save all that quote, plus sign balancing etc :-)

 The main reason I thought I'd play with it was just because I wanted
some simple debugging support but then it dawned on me that with a GUI
coming it might be useful to add localised GUI messages. It'd make it
easier for people to make it fit into their needs.
 
>
> 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).
>

I really like the aspect of WPKG nearly "working out-of-the-box".
Minimising file count is a very good practice.

 That thought urged me on to have a look at other alternatives to
creating a GUI for WPKG :-)
 
 I liked the designs people put forward but they had a number of extra
files attached and I thought it worth a shot trying out some of the
methods I've used elsewhere.

 The idea of the Language.xml was just that *if* it existed it could be
used to override the GUI messages. I wasn't thinking anything too funky,
just pre-loading default templates into a dictionary object. If the
language.xml file existed then overwriting the objects with the file
contents was easy.

The idea was very close to the config.xml parsing I thought.

 I hadn't anticipated the idea of localising packages though. That
I have to agree is beyond the scope of WPKG. I was more intent on the
idea that anything presented to user (or possibly the admin) had
potential to be customised/localised.

> 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.
>

 That would be cool :-)

>
> >  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?

 If the world was perfect, yes :-)

 From experience though, I've learned to distrust a lot of installers
made by hand or that use wizard-based installer generators. They tend
not to be as clear and precise about requirements.
 
 My example was a bit off, I think I probably should have really
emphasised the idea that it might install 'in-appropriately'.
 
 An installer will only check for meeting minimum requirements and
having software installed but unworkable because it's now running on a
machine that *just* squeezes past the minimum requirements is probably
something an admin might want support to avoid :-)

>
> 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.
>

  Yep. Here I made the mistake of not really getting the philosophy and
framework in my head properly. I see exactly what you mean but from this
and Falko's subsequent message it's apparent that this is any easy
mis-conception to make. People are looking effectively for two styles of
WPKG. I see how WPKG fits together better now.

 I'd like to write something proper for Falco as his comments went along
very similar thought patterns as mine and since reading it and having
the
'design' fall into place I'd like to push this discussion towards the
response I'll be sending him shortly. It just seems like a thread of its
own :-)

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

 Yep. I know what you mean there. I started out doing WMI queries and
working things out from that but the holes WMI's platform support soon
showed. I fell back eventually to file scripting object stuff.

> 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.
>

 Yep. That's the point I took on board :-)
 
 I'll re-write the bits I've done as external scripts giving exit codes.
 
 I used WMI here but in this case it was available across pretty much
every version of Windows. I made it simple, I just counted *if* a
machine had batteries. I didn't do anything fancy with power levels.
(That's another person to reply to.....)

> 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.
>

 Understood. I can see that building it into the 'language' of the
package.xml has bigger impact because the web interface also needs to
match it.

 When I get these ready where would you like them sent ?
 
>
>
> >  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?
>

 No problem :-)

  I get what you mean about avoiding globals. I totally understand
glitches as well ;-)

 The ones I'd spotted where the reuse of fso and wsh. I just thought it
was something that probably didn't really need data encapsulation as
their singletons anyway.

  If you need another pair of eyes to scan for the obvious ones I'm
happy to help out!

 I guess I'd better submit them as patches but I want to make sure
I catch up with messages :-)

>
> >  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.
>

 No probs.
 
 Neither of those two ideas are without their own issues. The ActiveX
obviously needs to be 'registered' and if you take the cheap route, that
I have, it adds a .NET dependancy. It's very easy to make a GUI using
that technique though. I had a prototype up in 15 mins.
 
 The HTA method has two major drawbacks. They're both surmountable but
it's a little tricky sometimes.
 
  HTA's are basically webpages with a few extra lines in them to make
them 'an application'. The extra lines say how the 'webpage' should be
put up as a dialog. The HTML is accessible as an object so you can
literally write to it as a DOM object.

  It's a neat idea but being essentially webpages the WScript object
doesn't exist for them.

   You can still create a WScript object and get information from it but
you don't get an arguments object. Instead you have to create the
WScript object, pull the commandline property from it and parse it. Most
of my design time was spent on a vbscript class to process that
commandline.
   
   The no. 2 problem is that it's very single-threaded. If you're
running a script it has a tendancy to not update the HTML/Dialog unless
you call something external to it (i.e. access an ActiveX object or
spawn a new process). The cheat for this is to do something like
WScript.Exec ("%COMSPEC%") whenever you modify the HTML. The spawning of
a new process give back some cycles to the HTA and it updates the screen
properly. It's a bit unergonomic but it certainly works.

	The VBScript vs JScript bit shouldn't be too much of a problem.
I
was quite surprised how easy it was to get the concepts. They both have
their own different styles but it's been quite refreshing to play with
JScript :-)
	
	Would you mind me sending the HTA I did to your e-mail address?
It
probably shows how you can use them better than I can in words....

   Would you like a copy of the ActiveX GUI source too?

>
>
> > 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

That's cool,

 WPKG is helping me out so I'd like to return the favour.
 
 Thank you for all the effort you've put in already and I hope that it
all goes swimmingly!
 
 I hope this hasn't been too useless!
 
 Have fun,
 
 Regards,
 
 Keith/Keefy
 
 PS: Look out for my reply to Falco, Tomasz etc :-)