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

[bugzilla-daemon at bugzilla.wpkg.org]

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





--- Comment #11 from Tomasz Chmielewski <mangoo at wpkg.org>  2008-01-14 14:38:22 ---
> About registry based communication:
> Personally I think the registry is not the best place for
> inter-process-communication (IPC). Registry is a permanent settings storage.
> Especially I have some concerns about the maintenance of these registry keys.
> If WPKG process is stopped or exits unconditionally it will probably not clean
> the values. WPKG client in such case cannot know if these values are still
> valid or not.

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.


> I think using STDOUT perfectly fits the needs of a one-way
> communication from WPKG to WPKG client.

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?

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.


That being said, perhaps there are better ways do do IPC than reading/writing
from/to the registry. Moreover, using the registry for IPC means constant
polling - it's not very elegant.
Are there any other alternatives? AFAIK, Windows doesn't have anything similar
to UNIX sockets.


-- 
Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.