[wpkg-users] [Bug 42] add a time parameter

[bugzilla-daemon at bugzilla.wpkg.org]

http://bugzilla.wpkg.org/show_bug.cgi?id=42





--- Comment #12 from Rainer Meier <skybeam at users.sourceforge.net>  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.