Wim,
You've made some valid points here.
You guys should consider linking to an example of a server side timer then.
Maurice, it's too bad you take it so personally.
Good luck.
2010/3/17 Dmitriy Igrishin <[email protected]>
> Absolutely agree with Overmind again. Wt (Webtoolkit) is designed to
> create highly interactive online web applications. Its API is
> widget-centric.
> Why invent another cron(8) to overload the library instead of
> implementing things which will help create complex GUI fast and easy?
>
> Regards,
> Dmitriy Igrishin
>
> 2010/3/17 OvermindDL1 <[email protected]>
>
> 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
>>
>
>
>
> ------------------------------------------------------------------------------
> 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
