Hey all, >> Quite frankly, coming from a user, WTimer should *only* be used with a >> session as it is the Javascript (meta-refresh?) interface, just as you >> would not use WText without a session (it is the <span> interface) or >> WTable, they are all client-side links. > > Why should it *only* be used from a session? No, sust because you say so is > not a valid technical argument. > I challenge you to provide properly substantiated grounds for you opinion on > this matter if you can.
The truth is, yes, currently WTimer requires a session because in fact it is the browser that waits for the suggested time before issuing a new request. In this way, you can properly modify the widget tree from within the timeout method and expect changes to be propagated to the browser. WTimer thus creates the illusion that you can push changes to the browser without actual server push (and it is indeed an alternative to server push). You are right that nothing in the interface suggests this, and therefore I agree that at least the documentation should clearly state this. It is also true that you could implement the same behaviour of WTimer when used without a Wt session. But I think that would actually open another question: what thread is used to run the WTimer call-back method? Is this a thread related to a WServer, and if so, then you do not indeed are not silently relying on a Wt session, but then you are silently relying on a thread pool of a Wt server instance. Surely, no one will be interested in a WTimer that spawns a new separate thread for running the call-back method. So, in practical terms, WTimer will still have a hidden dependency on another object. (Note in Qt, QTimer relies on the completely weird threading/event loop hybrid model and you cannot simply use a QTimer from any thread and expect it to work either) Given this API problem, and the fact that this requires a completely different WTimer implementation in addition to the current one (increasing binary size on embedded systems), I am not inclined to support this. If you want to use a timer outside the scope of a Wt session, I suggest to look at boost asio's timer support, which has a clear interface for defining what threads should be used to run the callback function. > Please try to understand that if a WTimer requires a session to work it > should probably > be called a WSessionTimer or similar. Is that not OO design 101? Clarifying the behaviour through documentation seems to me more effective than trying to convey this kind of information through a name (does a WSessionTimer time the duration of a session?). > The point is that neither the interface nor the documentation of many these > classes state anything about > the requirement for a session. The dependency on a session happens to be an > artifact of the current > *implementation*. Not really so: the dependency is because of its functionality: namely to support updates to a widget tree within the scope of a timeout. This requires cooperation of the web browser. Regards, koen ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ witty-interest mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/witty-interest
