Re: [wpkg-users] WPKG Client 1.3.4 released (testing release), including 64 bit support
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
Re: [wpkg-users] WPKG Client 1.3.4 released (testing release), including 64 bit support
Hi Tomasz, Tomasz Chmielewski wrote: 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. The fact that wpkg.js is a human-readable script does not change decisions regarding the architecture of the platform. There is no reason why WPKG client could not use localization (lots of open source projects support multiple-languages by localization files). But the main issue which was not taken into consideration is that WPKG client needs to parse the information forwarded by wpkg.js in order to display some output on the GUI. Of course wpkg.js could forward the messages exactly the same way as they should be displayed. However that is only the easiest possible solution. I had a much more advanced interface in mind where WPKG client parses the output of wpkg.js and displays some much more nice figures (diagrams, progress bars etc.). This is only possible if WPKG client can easily parse the output of wpkg.js. This is exactly the reason why I push to clearly split up components using the MVC pattern. The sendStatus interface is a clear data interface between two components. It is not a GUI interface where wpkg.js displays messages to the end user. It is just forwarding data. If wpkg.js would translate the messages (for example by defining messages within config.xml) then it makes it almost impossible for WPKG client to parse this printouts since they might look different on each installation. In particular some of the fields presented to WPKG client currently might be omitted then since somebody does not like to see the progress (1/14) on the end user screen. 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. Something like this - or another moving element could be helpful. Like such a popular turning circle animation (vista hourglass replacement or Firefox loading indication). Personally I don't see the reason why we should still use two alternating messages. It could also be one single message and having another element on the GUI showing/faking some activity (in addition to the progress bar which could freeze for some time). Earlier I also suggested some kind of Statistics. From the data transmitted by the sendStatus function the following fields on the GUI could be displayed (below progress bar probably): - Deployment started at : date when synchronization started - Total run time : current time - start time - Current package install duration: current time - install start time The time values could be updated each second which also shows some progress to the user. 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. Well right - see above for some more ideas. 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? Well a progress-bar implicitly indicates some percentage. WPKG client could calculate this from the sendStatus output (as suggested). However displaying some absolute
Re: [wpkg-users] WPKG Client 1.3.4 released (testing release), including 64 bit support
Rainer Meier schrieb: In fact I also thought about extending the package format to include some package description (which can be provided in various local languages). Then it would be possible to print this information to sendStatus output as well. So WPKG client could display some nice information about the application currently being installed/upgraded. OK, you had something like that in mind. Sounds sophisticated... we'll see. Perhaps a simple / extended view switch would be desired (not sure if by the admin, in wpkginst.exe, or in the delay window), or both, if admin permits extended view. Let's outline the GUI as I see it: | WPKG package deployment | | | | Deployment started at: xx:yy:zz [ACTIVITY] | | Running since:yy:zz [INDICATOR] | | | | Stage: [Remove|Install] | | Package 2 of 10: Adobe Acrobat Reader| | __ | | |-|| | | -- | | Package status: | | Installation started at: xx:yy:zz| | Running since :yy:zz| | Description: | | __ | | | Adobe Acrobat reader |^| | | | Acrobat reader is used to display PDF files. | | | | | [some more information about the reader] | | | | ||v| | | -- | |__| From my point of view such a windows would provide quite a fair amount of information to the (waiting) user. You forgot about one important thing (below the activity indicator): | WPKG package deployment | | | | Deployment started at: xx:yy:zz [ACTIVITY] | | Running since:yy:zz [INDICATOR] | | | | Stage: [Remove|Install] [LAUNCH GAME TO] | |Package 2 of 10: Adobe Acrobat Reader[KILL SOME TIME] | | __ | ;) -- Tomasz Chmielewski http://wpkg.org - Reporting bugs, all WPKG mailing lists http://wpkg.org/Support ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
Re: [wpkg-users] WPKG Client 1.3.4 released (testing release), including 64 bit support
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. This is more compliant to the MVC principle. Here wpkg.js is the server/controller part and WPKG client would be the view part. In general I think the GUI should do localization and data exchange between the controller and the view should be a technical, language-independent format. We might even think about different GUI styles later. One GUI might display the names of the packages, others might just display a blinking caret and print the number of packages installed... - 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. br, Rainer - Reporting bugs, all WPKG mailing lists http://wpkg.org/Support ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
Re: [wpkg-users] WPKG Client 1.3.4 released (testing release), including 64 bit support
Helo Rainer, thanx for your quick reply. - 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. Ok, ACK - so this means Wpkg Client would get the messages from wpkg.js and localize them e.g. through config.xml for display. - 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. Yes, this is clear. It's just an idea for convenience: if I restart the wpkg service on local or remote pc from Wpkginst tool I don't have to open event log viewer, connect to the Client, open events, open application and have a look through the messages. Easily I could have a look at the messages in wpkg tool. Perhaps a button / link to open the application event log of the pc there I (re)started wpkg would be ok, too. Opening the event log of the pc and filter for WSH is perhaps easier to integrate in wpkginst than opening the log file for the client, isn't it? Best regards, Falko -- Falko Trojahn fon +49-341-3581294 Dipl-Ingenieur Netzwerke/Support fax +49-341-3581295 SMI Softmark Informationstechnologien GmbH - Reporting bugs, all WPKG mailing lists http://wpkg.org/Support ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
Re: [wpkg-users] WPKG Client 1.3.4 released (testing release), including 64 bit support
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Falko Trojahn Sent: 08 July 2008 13:03 To: Rainer Meier Cc: wpkg Subject: Re: [wpkg-users] WPKG Client 1.3.4 released (testing release), including 64 bit support Yes, this is clear. It's just an idea for convenience: if I restart the wpkg service on local or remote pc from Wpkginst tool I don't have to open event log viewer, connect to the Client, open events, open application and have a look through the messages. Easily I could have a look at the messages in wpkg tool. Perhaps a button / link to open the application event log of the pc there I (re)started wpkg would be ok, too. Opening the event log of the pc and filter for WSH is perhaps easier to integrate in wpkginst than opening the log file for the client, isn't it? [Leon Hedding] I sort this issue by using centralized logging that I can run tail -f upon. I do this by modifying wpkg.js to not overwrite the log file and by adding log rotation to wpkg.js. The reason I don't use logrotate is because WPKG might not be installed on a Windows box which does not have this installed and because I could not be bothered trying to figure out how logrotate would work with my logging scheme. [Leon Hedding] - Reporting bugs, all WPKG mailing lists http://wpkg.org/Support ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
