John Dickinson wrote:
I have also updated the wiki with similar changes (splitting the
javascript, allowing polling to be disabled and stopped once it is
going). It's probably slightly different than your changes in svn, so we
should probably figure out which is better suited to the necessary t
I am still not convinced that polling is a good solution for long queries.
One good reason for this is that you can't implement real time
application anymore: a chat board, real time stock quotes, etc...
Isn't it better to store the tcp socket file handles left open in a
connection pool?
As so
I have also updated the wiki with similar changes (splitting the
javascript, allowing polling to be disabled and stopped once it is
going). It's probably slightly different than your changes in svn, so we
should probably figure out which is better suited to the necessary tasks
and go with that
I have now incorporated your ajax_clientPollingInterval() to AjaxPage as
well and separated the responseTimeout parameter from the clientPolling
flag. Adding some more docstrings and splitting the Javascript in two
parts now makes the whole thing much better understandable.
-- Christoph
Sorry, I should have waited for your response before doing it on my
own. That looks good. However, I really would like to be able to
switch off the polling completely. This spares loading and running the
Javascript for the polling mechanism, and the shutdown, with all
possible Javascript erro
John Dickinson wrote:
Instead of turning the polling off, would setting the client polling
interval to some big number be good enough? I added an
ajax_clientPollingInterval to AjaxPage so that a child page can easily
set the polling interval (long if it doesn't need it, short if it does).
Sor
sophana wrote:
I agree with you that webware is not designed for doing this kind of stuff.
If you want to do long running queries, I suggest that you bypass apache
and webware, and implement a separate dedicated (python) server that
supports these very long running queries, without the timeout
However, I'm actually wondering whether you really always need to run
this background polling. If requests are always answered within the
timeout interval (which is set to 100 seconds), that mechanism should
be never needed. For instance, in the "AjaxSuggest" example, it will
be surely not ne
However, I'm actually wondering whether you really always need to run
this background polling. If requests are always answered within the
timeout interval (which is set to 100 seconds), that mechanism should
be never needed. For instance, in the "AjaxSuggest" example, it will
be surely not ne
John Dickinson wrote:
I've got a new implementation that solves both of these problems, but I
can't seen to get in to the wiki to post it.
Thanks a lot. I have already checked it in to the SVN repository.
BTW, I have restarted the Wiki and let it use the current Webware 0.9.
Should be better
I stand corrected.
[EMAIL PROTECTED] - You are in a maze of twisty integration
histories, all alike.
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Atte
sophana wrote:
> Jeff With The Big Yellow Suit wrote:
>
>>> If someone could explain, I would be grateful...
>>
>> If I'm interpreting your questions and statements correctly
>> then you seem to have two misunderstandings. One is about
>> how HTTP requests work, and the other is about the costs
Jeff With The Big Yellow Suit wrote:
> If someone could explain, I would be grateful...
If I'm interpreting your questions and statements correctly
then you seem to have two misunderstandings. One is about
how HTTP requests work, and the other is about the costs
of threading. Please forgive m
John Dickinson wrote:
I think I understand now.
The client is polling the server for new data that could come up
because of external events.
If I understand correctly, this kind of application is useful for a
certain class of websites like chat, real time data updating (like
stock quotes),
I think I understand now.
The client is polling the server for new data that could come up
because of external events.
If I understand correctly, this kind of application is useful for a
certain class of websites like chat, real time data updating (like
stock quotes), etc..
In majority of
> If someone could explain, I would be grateful...
If I'm interpreting your questions and statements correctly
then you seem to have two misunderstandings. One is about
how HTTP requests work, and the other is about the costs
of threading. Please forgive me if I've gotten either of these
interp
John Dickinson wrote:
In answer to your first set of questions, ajax_response() waited to
see if anything would show up in the response bucket that needed to be
sent to the client. Once something showed up, it was send down the
pipe to the client, and the connection was closed.
What kind of
But there is thread switching going on all the time. The more threads,
the more switching overhead.
I don't think we talk about the same threads.
python is an interpreted language. There is absolutely no overhead in
switching a python context. Nothing similar with a regular os thread switch.
In answer to your first set of questions, ajax_response() waited to see
if anything would show up in the response bucket that needed to be sent
to the client. Once something showed up, it was send down the pipe to
the client, and the connection was closed. The client would then reopen
the conne
sophana wrote:
Michael Palmer wrote:
Geoffrey Talvola wrote:
John Dickinson wrote:
Not only that, it consumes a webware thread that could be used for
other requests.
Yes, this won't scale too well if you have large numbers of concurrent
users. You could probably handle hundreds of
They are handled like standard requests. The issue is that (in my
older implementation) the request would be made to the server, and the
server would sit around with that request for TIMEOUT seconds.
That is my question: Why waiting?
Why not immediately close the connection and the thread
I haven't understood why ajax requests require a busy thread to be
handled.
Is it because the tcp connection is not closed between the requests?
Why ajax requests are not handled like standard http requests, using a
session Id to maintain the per client state (with a new tcp connection
per
Michael Palmer wrote:
Geoffrey Talvola wrote:
John Dickinson wrote:
Not only that, it consumes a webware thread that could be used for
other requests.
Yes, this won't scale too well if you have large numbers of concurrent
users. You could probably handle hundreds of users with a large
Geoffrey Talvola wrote:
John Dickinson wrote:
Not only that, it consumes a webware thread that could be used for
other requests.
Yes, this won't scale too well if you have large numbers of concurrent
users. You could probably handle hundreds of users with a large thread pool
though.
Acc
John Dickinson wrote:
> Not only that, it consumes a webware thread that could be used for
> other requests.
Yes, this won't scale too well if you have large numbers of concurrent
users. You could probably handle hundreds of users with a large thread pool
though.
Nevow/Twisted solves this proble
and, of course, as soon as I sent my message, I could get in to the wiki
and update it.
wiki.w4py.org/ajax_in_webware.html
wiki.w4py.org/ajaxpage.html
wiki.w4py.org/ajaxjavascript.html
--John
John Dickinson wrote:
Not only that, it consumes a webware thread that could be used for
other reques
Not only that, it consumes a webware thread that could be used for other
requests.
All in all, that implementation was flawed.
I've got a new implementation that solves both of these problems, but I
can't seen to get in to the wiki to post it. The basic idea, though, is
to move the work from
27 matches
Mail list logo
