[wpkg-users] WPKG Client 1.3.4 released (testing release), including 64 bit support

[Tomasz Chmielewski]

Rainer Meier schrieb:
> Hi Falko,
> 
> Falko Trojahn wrote:
>> - it would be nice to have the installation status messages localized via
>> config.xml - this could be easily adapted in wpkg.js using the existing
>> getLocalizedString() function?
> 
> I thought about this but my initial idea of localization of status 
> messages has been slightly different.
> The messages printed by wpkg.js (to be read by the GUI process) should 
> be easily readable by the GUI in order to display status information 
> (not just pass-on the text printed by WPKG).
> 
> For example I had in mind that the GUI could display some progress bar 
> (or even cake diagrams or whatever)...
> 
> For that I created some easy-to-parse printouts. So actually I think the 
> GUI should be responsible to display localized information to the user - 
> just receiving technical data from wpkg.js.

I beg to differ here.
The main reason is that wpkg.js is an interpreted, human-readable 
language, and thus, can be easily changed by virtually every admin.
WPKG Client, on the other hand, is a binary, and virtually no one can 
change the way it interprets the data in gets from wpkg.js, unless 
someone modifies a source of a complicated language (when compared to 
JScript), compiles it from scratch, and redistributes to dozens of 
workstations.


(...)

But first, before we argument some more, we have to define what data we 
would like to display in a logon/shutdown delay window. First, let's 
take a look at wpkg.js /sendStatus output:

2008-05-16 12:49:02, STATUS  : Starting software synchronization
2008-05-16 12:49:02, STATUS  : Number of packages to be removed: 0
2008-05-16 12:49:02, STATUS  : Install: Verifying package 'KB888111' (1/14)
2008-05-16 12:49:02, STATUS  : Install: Verifying package 'Mozilla 
Firefox 2.0' (2/14)


And here are some of ideas for the logon/shutdown delay window, we have 
some of them already:

1. Obviously, we need some messages that change every few seconds (these 
two defined in wpkginst.exe) - it signals the user that everything is fine.

2. Because some users don't read messages displayed by a computer, 
something "that moves" on a screen is needed. Currently, we have a 
"pseudo progress bar".

3. What about a real progress bar? After all, at the wpkg.js outputs its 
progress, by using (1/14), (2/14) and so on. To be frank, I'm not very 
sure about this. In certain scenarios (a classroom full of workstations 
connected over wireless, installing something heavy, like Office). As 
wireless + many workstations = slow, it will mean the progress bar will 
halt for several minutes. Users, room cleaners etc. other non-technical 
people are very often friendly people, and sometimes they just "hey, the 
progress bar hanged on some of the machines, so I just restarted them, 
you don't have to thank me!".
So what about displaying a percentage, in numbers (7%, 58% etc., 
calculated basing on (1/14), (2/14)...) in a "pseudo progress bar"?

4. /sendStatus displays things like "Install:" etc. - I don't see why it 
can't be delivered in a proper form by wpkg.js (changeable in 
config.xml). After all, WPKG Client interacts with only one program 
(wpkg.js), an there are no plans to change it.



>> - I know, there has been yet a similar discussion about that in the list,
>> but: would it be possible to get the sendStatus messages (or, at least,
>> the event log messages with source WSH and Wpkg Service) on the Wpkginst
>> tool page after (re)starting the (remote/local) Wpkg Service?
> 
> Hmm, I am not sure what is the purpose of this request. Any tool could 
> read the event log messages from WPKG from the event log and display 
> them. The sendStatus messages are used only to communicate the current 
> state of WPKG to the GUI using STDOUT. Of course WPKG GUI could display 
> a kind of "log" what it received. But this would be more a kind of 
> debugging option. These status updates are not written to event log on 
> purpose since as I wrote above they are meant to be an internal 
> communication channel between the components.

The purpose of this request, I presume, would be seeing what happens on 
the client in one place:
- start wpkginst on any machine
- (re)start WPKG service on a remote machine
- watch what fails and what succeeds

If such a feature had any value to the admin, it should not just display 
  sendStatus messages, as it doesn't really contain lots of debugging info.

So we would need:
- more STATUS info from wpkg.js
- some (secure) mechanism to send data between a remote WPKG service and 
a local wpkginst.exe

Which sounds like considerable effort.


I personally do wpkg.js logging (for each workstation) on a central 
Samba server, and just "tail -f" a the file in question there, and 
didn't really think of viewing that on a workstation running wpkginst.exe.
In fact, I wanted to extend this feature by adding a possibility to 
start/stop the service on a list of clients (feed either from a file, or 
by typing/pasting more workstations into the box). Now I need someone to 
figure out how to make wpkginst.exe show sendStatus info for dozens of 
workstations ;)



-- 
Tomasz Chmielewski
http://wpkg.org