Mailinglist Archive: yast-devel (129 mails)

< Previous Next >
Re: [yast-devel] Wt and Yast
  • From: Stanislav Visnovsky <visnov@xxxxxxx>
  • Date: Wed, 28 Nov 2007 09:48:12 +0100
  • Message-id: <200711280948.12888.visnov@xxxxxxx>
Dňa Tuesday 27 November 2007 23:06:13 Wim Dumon ste napísal:
On Nov 26, 2007 4:32 PM, Stanislav Visnovsky <visnov@xxxxxxx> wrote:
Hi Wim!

Cool to see you here!

It's our pleasure to see that Wt is considered for Yast.


The biggest issue I've faced was the fact that almost every functionality
in the Wt classes went down to figuring out the session, and this info
seems to be depend on the boost thread-local storage. So, I needed to be
very careful in which thread I'm running, creating additional overhead.

See my other post, I think you should structure it differently so that
you don't need any thread switching at all.

YaST has a base component library, which provides the main() function.
This function evaluates the commandline arguments, picking client
(typically YCP code) and server (typically UI).

You should accept that a single web daemon will be able to serve
multiple yast sessions, and thus it is started in a way not specific
to a particular user, but rather as a plain daemon.

The way you start yast from the command-line is on the same level as
where a particular user surfs to the daemon and starts a new session.
That will cause the 'create application' callback (argument of
Wt::WRun) to get called, from which you have to return a WApplication
object. If multiple users are surfing to the Yast website
simultaneously, multiple Yast applications are running simultaneously,
either as separate unix processes or within the same unix process,
depending on your wt deployment options.

In threaded example, YCP code is started and when it first encounters UI
call, it calls the UI component (*). The component then finally creates a
real UI, starting a thread to handle events and redraws (call it UI
thread). Every UI call from YCP synchronizes with the UI thread via 2
pipes implementing message passing, the real UI functionality is always
evaluated in the UI thread.

I suggest you do something like this, since it only changes the
bootstrap, and considers the YCP as a "worker" thread spawned from the
Wt event loop:

- createApplication() [in the Wt thread], creates a YCP thread, and
waits for a synchronization signal from the worker thread.
- YCP thread triggers UI code which sets up synchronization pipes and
signals the Wt thread
- Wt thread creates the WApplication and (and anything else). From
here on it should be the same story as the Qt UI, but instead of
running app->exec() method, it returns the Application instance.

Bottom line: As Wt is an 'application server', it can cause multiple
Yasts to be started (one per user surfing to the application server).
We recommend to write your program in such a way as if the 'create
application' callback that you specified as parameter of Wt::WRun() is
the 'main()' function of what you would have written in a Qt
application. The main task of main() in a Wt application is to call

What we've been trying to do is to integrate into already existing YaST
structure and this seems to be not possible easily. I agree with your
suggestion, however, this means a fundamental change how YaST deals with its
UIs. OTOH, it might be a good idea to change it? ;-)

To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >