On Tue, Mar 16, 2010 at 6:11 AM, Maurice Gittens <[email protected]> wrote: > Hi OvermindDL1, > > Thank you for you opinion. > > On Tue, Mar 16, 2010 at 1:08 AM, OvermindDL1 <[email protected]> wrote: >> >> On Mon, Mar 15, 2010 at 9:39 AM, Maurice Gittens >> <[email protected]> wrote: >> > /* snip */ >> >> 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.
Er, re-read what I said, the valid technical argument is that, like everything else in Wt, it is an interface into a remote client function, which of course requires a Session. On Tue, Mar 16, 2010 at 6:11 AM, Maurice Gittens <[email protected]> wrote: > 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? Absolutely not! Do we call WText WSessionText? No, that would be stupid, because everything in Wt is a remote interface into a client side session. And that may be OO design in the Java world, but not for the smarter languages. On Tue, Mar 16, 2010 at 6:11 AM, Maurice Gittens <[email protected]> wrote: > 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*. They do not state it, because everything requires it, that is the *very* design of Wt. Wt is a remote gui interface, it is not local. We could easily make a WText that runs without a session too, what shall it do, print to cout, that makes sense, and it could be made that way, but quite frankly, just like making WTimer have a server-side implementation, is just plain stupid in the design. On Tue, Mar 16, 2010 at 6:11 AM, Maurice Gittens <[email protected]> wrote: > So when, for example, one needs to serve JSON without a session and one > serves stuff including strings > from a resource bundle should it not be supported just because you do not > have > this need? Great! Thanks for your consideration. Strings can be served without a session just fine, because those are stateless, but WTimer is stateful, as are things like buttons, listboxes, etc... Hence, they need a session. On Tue, Mar 16, 2010 at 6:11 AM, Maurice Gittens <[email protected]> wrote: >> If you want to work in the >> background, do not use Wt client interfaces. If you want a background >> timer, use it as your normally would, ASIO::timer or sleep or >> what-not. >> > > It helps when people recognize that there are more use-cases than their own. > What I suggest takes nothing away from your use case _and_ adds new use > cases > for other folks. Why do you oppose this? Again just because you can is not a > valid > technical reason. It is not 'my' usecase, it is the way Wt was designed. Wt is a remote interface into a client-side gui. I can oppose that because WTimer is a remote javascript implementation (or perhaps a meta-refresh if javascript is disabled), neither of those make *any* sense in the context of running on the server. On Tue, Mar 16, 2010 at 6:11 AM, Maurice Gittens <[email protected]> wrote: > Supporting new use-cases without: > - removing existing functionality > - breaking existing code > - significantly adding/changing existing interfaces > - using significantly more resources > - causing significant regressions > > is exactly what Wt needs. But it does make it vastly harder to maintain as you are mixing multiple different paradigms. WTimer is a remote interface. To do something locally, use a local interface, like QTimer or ASIO::timer or sleep/Sleep. On Tue, Mar 16, 2010 at 6:11 AM, Maurice Gittens <[email protected]> wrote: > Do you really think that use of Wt will grow more by reducing the number of > situations > in which it can be used? Not reducing anything, WTimer is perfect for the context for which it was created, a remote client-side interface. On Tue, Mar 16, 2010 at 6:11 AM, Maurice Gittens <[email protected]> wrote: > I have written enough well-used homegrown C++ application servers and I > personally do not > need Wt be improved to support more used cases. > But I use Wt simply because I like the idea of a open-source C++ Web > Application framework. > In fact I will probably just roll my own fast-cgi application server and > move on; because my code > is written so that it is easy to get rid of Wt. Ditto, and I have been half-tempted to because of how nasty-Java'ish Wt feels (and the horrible license, does not fit in with the Boost-style license I use for all my code), but no sense re-inventing things. On Tue, Mar 16, 2010 at 6:11 AM, Maurice Gittens <[email protected]> wrote: > But is it that hard to grasp that it is not good for the Wt user-base when a > more diverse set of > use-cases is not supported? Sure, but the use-case of Wt *itself* is a remote client-side interface. Adding functionality above that makes it harder to maintain, and is already quite stupid since things like ASIO (which comes with Wt) already includes a server-side timer. As I am sure you know, it is also stupid to duplicate identical functionality in a single project. ------------------------------------------------------------------------------ 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
