http://bugzilla.wpkg.org/show_bug.cgi?id=42
--- Comment #12 from Rainer Meier <[EMAIL PROTECTED]> 2008-01-14 22:47:50 --- #10 > > 2008-01-12 20:30:00 - WPKGSTATUS Starting software synchronization > > 2008-01-12 20:30:02 - WPKGSTATUS Tasks: INSTALL 3; UNINSTALL 2 > > 2008-01-12 20:30:03 - WPKGSTATUS Removing package: Mozilla SeaMonkey > > 2008-01-12 20:32:00 - WPKGSTATUS Removing package: QuickTime Lite > > 2008-01-12 20:32:00 - WPKGSTATUS Installing package: Mozilla FireFox > > 2008-01-12 20:33:30 - WPKGSTATUS Installing package: QuickTime Alternative > > 2008-01-12 20:35:00 - WPKGSTATUS Installing package: WinMerge > > 2008-01-12 20:36:10 - WPKGSTATUS Finished software synchronization > Hi This looks totally ok with me. If i understand it correctly it counts the > actual time that has gone with the installation(s) No, not exactly. I meant to pass on the actual start of the event. Which means when it started. This would allow the GUI to count the time passed since the command was started by itself (until next command or finished message is displayed. By the announcement how many operations (install/uninstall) will be executed the GUI can display some basic progress bar or a message like (x of y packages processed). #11 > If "cscript wpkg.js" exits/dies, WPKG Service knows it immediately. Even if > there are any unclean values there, we don't read them anymore. And on > startup, > wpkg.js (or even WPKG Client too) could clean the state properly - again, no > problem. Basically this is true. However I think in this case we should have clear responsibilities which tool is cleaning up - I would suggest the one which writes the information will do the cleanup as well. > Indeed, but what if we want WPKG Client to talk to wpkg.js one day? We have to > invent a new interface. When it might be useful? Hmm, I can't think of a good example yet. Moreover I still don't think that communication using the registry is the right approach. The main reason for it was given by you directly: polling. One of the most ugly things in IT technologies. > Some installers don't work properly when started in a "virtual GUI" (not on > the > primary display) - this is what WPKG Service normally does when it starts > programs - users won't see/interrupt any installers. As wpkg.js is a child, it > can't display anything as well. So an idea would be something like > showgui="yes" in the XML, where wpkg.js would pass the install command to WPKG > service - to be executed in the real GUI. Obviously, WPKG service has to tell > wpkg.js what was the exit code for the installer. I hope you're not really thinking about WPKG client to store the exit code within the registry and WPKG.js is checking frequently if it is available (polling). I even don't want to think about it since I am too far away from the toilet... Alternative proposal: There might be a possibility to listen on a TCP port so WPKG could use a simple transfer protocol (probably HTTP-based). Both wpkg.js and WPKG client could implement such a listener. wpkg.js could send message updates to the WPKG client listener and the other way round. However I have no clue if this is feasible with a JScript (no doubt it's possible for WPKG client). In any case it would need changes in both applications and a clear definition of transfered message format and types. Currently the main need seems to be to display more information on the pre-login banner so the user is informed that the machine is doing something (and what). This could be done by simple STDOUT/STDIN communication and currently we just need one-way communication. If in the future we will implement TCP/IP based communication it might be very easy to upgrade (while even keeping backwards compatibility). PS: I probably did not fully understand your example. If WPKG client is running as a service of course it's not allowed to interact with the desktop (unless the service allows so, which is not recommended). Of course in such case also wpkg.js and its childs (insatllers) cannot display anything. In that case even sending the command to WPKG client will not help since WPKG client also does not have the rights to show the GUI. If WPKG client is allowed to interact with the desktop then wpkg.js will be allowed as well - so no need to transfer the command. Transferring the command is again a one-way communication from wpkg.js to WPKG client (which can be done using STDOUT). What remains is returning the status code which is not really needed as of the fact that executing the command by WPKG client does not change anything on the process/child rights of desktop interaction. Probably there is a reason but I can't think about an example yet. A "cancel" or "stop" button on the GUI also does not justify bidirectional communication since stopping a child can e done using signals, you just kill the sub-process. WPKG currently just uses static information from XML files as an input. So there is no run-time value read from the system after initialization. So currently I don't see any need to push data to WPKG at any time when it is running. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. ------------------------------------------------------------------------- Do you use WPKG? Tell us how! >> http://wpkg.org/Testimonials _______________________________________________ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users