greg wrote:
Jay Loden wrote:
Like most things involving dynamic client side-javascript code and AJAX
technology, it's a lot harder than you'd like it to be to solve the problem,
but
in cases where the Back button is really an issue, it's worth the effort.
So if you're willing to put in a
Jay Loden wrote:
Like most things involving dynamic client side-javascript code and AJAX
technology, it's a lot harder than you'd like it to be to solve the problem,
but
in cases where the Back button is really an issue, it's worth the effort.
So if you're willing to put in a huge amount of
Steve Holden wrote:
greg wrote:
Jay Loden wrote:
Like most things involving dynamic client side-javascript code and AJAX
technology, it's a lot harder than you'd like it to be to solve the
problem, but
in cases where the Back button is really an issue, it's worth the effort.
So if you're
In article [EMAIL PROTECTED],
Paul Rubin http://[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Cameron Laird) writes:
Others have answered this at other levels. In elementary terms,
there truly is a difference, Paul, and one that's widely reified:
a desktop client-server application typically
Cameron Laird wrote:
In article [EMAIL PROTECTED],
Paul Rubin http://[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Cameron Laird) writes:
Others have answered this at other levels. In elementary terms,
there truly is a difference, Paul, and one that's widely reified:
a desktop client-server
Steve Holden wrote:
As far as I'm concerned the major issue with trying to have desktop web
apps compete with true windowed applications is the difficulty of
maintaining sensible interactions with the interface. AJAX designs have
increased the interaction level at the expense of greater
[EMAIL PROTECTED] (Cameron Laird) writes:
application in the web app model (I haven't even touched on the whole
stateless HTTP being mapped to a stateful environment issue, or the
need to manage the local web server) actually buys you anything. I
.
Go ahead: touch on
Paul Rubin http:/...nvalid wrote:
[EMAIL PROTECTED] (Cameron Laird) writes:
application in the web app model (I haven't even touched on the whole
stateless HTTP being mapped to a stateful environment issue, or the
need to manage the local web server) actually buys you anything. I
.
Go
Paul Rubin wrote:
I'm not sure what you're getting at in this context. You can write a
desktop app where the window system communicates with a gui toolkit
through a socket (at least that's how X windows works)
An X server connection is *much* more stateful than
an HTTP one. It persists
greg [EMAIL PROTECTED] writes:
An X server connection is *much* more stateful than
an HTTP one. It persists throughout the entire use
session of the application, for one thing, and there
is heaps of state being kept on both sides of the
connection. There's also a very high communication
In article [EMAIL PROTECTED],
Paul Rubin http://[EMAIL PROTECTED] wrote:
.
.
.
I'm not sure what you're getting at in this context. You can write a
desktop app where the window system communicates with a gui toolkit
through
Paul Rubin wrote:
The high bandwidth and persistence is not needed for an http
connection, which just gets a form submission once in a while.
Bandwidth isn't really the main issue. The point is
that a lot of state is kept on both ends, making it
much easier to implement a rich user interface.
[EMAIL PROTECTED] (Cameron Laird) writes:
Others have answered this at other levels. In elementary terms,
there truly is a difference, Paul, and one that's widely reified:
a desktop client-server application typically listens through
one socket, which therefore constitutes an index of the
In article [EMAIL PROTECTED],
Chris Mellon [EMAIL PROTECTED] wrote:
.
[scores of lines
of vigorous debate]
.
.
Moreover, if you *don't* need global access or zero-deployment
(zero-deployment is
14 matches
Mail list logo
