Hello Koen,
On Mon, Mar 15, 2010 at 3:30 PM, Koen Deforche <[email protected]> wrote:
> Hey Maurice,
>
> 2010/3/15 Maurice Gittens <[email protected]>:
> > Hi,
> >
> > On Mon, Mar 15, 2010 at 11:00 AM, Torsten Schulz <[email protected]>
> wrote:
> >>
> >> Hello,
> >>
> >> it's my opinion too. Many times I'll integrate a timer in background.
> >>
> >> Greetings
> >> Torsten
> >>
> >
> > Let me add a me too!
>
> Let us see how we can make WTimer useful outside of a session...
>
> Would you then want to have the timeout slots() fire in a thread from
> the server thread pool or from a specific thread ?
>
>
I suggest we take a step back and consider the design of the Wt interfaces
without
complicating the discussion with implementation details.
Let us consider the interface of WTimer.
WTimer<http://www.webtoolkit.eu/wt/doc/reference/html/classWt_1_1WTimer.html#1fb659aac40b49b3ec7631d558884847>(
WObject<http://www.webtoolkit.eu/wt/doc/reference/html/classWt_1_1WObject.html>*parent=0)
Construct a new timer with the given parent.
~WTimer<http://www.webtoolkit.eu/wt/doc/reference/html/classWt_1_1WTimer.html#6b983b4aa0a3594cad4a236f5a4acd0b>()
Destuctor.
int
interval<http://www.webtoolkit.eu/wt/doc/reference/html/classWt_1_1WTimer.html#3aedc0ad65a5d57bea4b805a92d7736d>()
const
Returns the interval (msec).
void
setInterval<http://www.webtoolkit.eu/wt/doc/reference/html/classWt_1_1WTimer.html#3a4070540a6b0e10bf1ee7bd607334fc>(int
msec)
Sets the interval (msec).
bool
isActive<http://www.webtoolkit.eu/wt/doc/reference/html/classWt_1_1WTimer.html#eabde106e48ea67e10c4043609b85493>()
const
Returns if the timer is running.
bool
isSingleShot<http://www.webtoolkit.eu/wt/doc/reference/html/classWt_1_1WTimer.html#61dd8a5ac6fc6d9bd995e08ff7fae83c>()
const
Is this timer set to fire only once.
void
setSingleShot<http://www.webtoolkit.eu/wt/doc/reference/html/classWt_1_1WTimer.html#92ae68d15de600174afdd2e443397604>(bool
singleShot)
Configures this timer to fire only once.
void
start<http://www.webtoolkit.eu/wt/doc/reference/html/classWt_1_1WTimer.html#e167fbd3eb981a2fce52e9a4b3b6e0af>()
Starts the timer.
void
stop<http://www.webtoolkit.eu/wt/doc/reference/html/classWt_1_1WTimer.html#73c5d1b882af4835384ccdc07a650e34>()
Stops the timer.
EventSignal<http://www.webtoolkit.eu/wt/doc/reference/html/classWt_1_1EventSignal.html><
WMouseEvent<http://www.webtoolkit.eu/wt/doc/reference/html/classWt_1_1WMouseEvent.html>>
&
timeout<http://www.webtoolkit.eu/wt/doc/reference/html/classWt_1_1WTimer.html#2a66c6a51df2b0ab42258abf2ebd0399>()
Signal emitted when the timer timeouts.
Notice that nothing in the interface of this class (or the associated base
class) implies
a requirement on a session?
The point I am trying to make is that dependencies between classes should be
made apparent in
their associated interfaces. Otherwise the only way to use Wt effectively is
by reading the source.
Other WObjects also seem to have the issue of dependencies not documented in
the documentation of the
interface.
> > This is another instance of the issue I encountered with using a WText
> > without a session and
> > using a WResource with a session.
>
> You probably mean a WResource without a session?
>
>
Sorry, I mean it as I wrote it.
The concept Wt needs to adhere to is known as orthogonality.
In principle Sessions and (most?) WObjects are orthogonal concepts and Wt
needs to
recognize them as such.
IMO, the fundamental issue you tried to fix last week (in support for
Restful Wt services) by allowing per
session WResources with their own internal path, is also a consequence of
missing orthogonality
between Sessions and WResources.
> So, if I understand well, you want to have complete "off-line" support for
> Wt?
> You could probably do all of this already now, when using a
> WTestEnvironment?
>
> > I hope Emweb fixes the conceptual bug rather than trying to solve the
> same
> > problem
> > many times and running the risk of inventing many inconsistent solutions
> to
> > what is in essence
> > the same problem.
>
> The way I understand it now: the essence is having off-line applications ?
>
>
IMO, there are two key issues here:
1. the clean interfaces.
The requirements for using a class such be dictated by their interfaces.
2. Orthogonal design.
In _principle_ all WObjects need to be usable with and without a session,
when this is not
the case the interface and/or documentation of a particular WObject class
needs to reflect
all requirements.
Possibly, the fix is not very difficult, so my suggested solution follows.
Currently, Wt maintains a per session widget tree which it rewrites/renders
for each request.
All that needs to be done is to add a session independent (on WServer?)
widget tree which, by default
would be used in all cases where there is no current session.
This way all WObjects which work with a session would also work without a
session by using the
session independent stuff when there is no current session available.
Notice that this solution allows you to avoid changing the interfaces? I
think this is what
Emweb needs to want. More functionality with fewer interfaces.
Of course, this suggested solution path is from the perspective of a very
casual Wt user.
Thanks for looking at this stuff.
Cheers,
Maurice
> 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
>
------------------------------------------------------------------------------
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
