Basic question on RoR, the Web, and Browsers

Let's say Firefox has opened two tabs each with Google's home screen on
it.

Now the user enters some text into the form and clicks "Google Search".

If Google were implemented in Rails, some controller would see the
request, process it, hand off to a view, and the view would render it.

Basic question: When the view is rendered and sent back to the client
browser, how does the browser know what tab to render?

- - - -

Here's my "real" problem. I am clueless how to implement this. No,
this is not a homework assignment.

What I want to do is have two tabs (that is, two "users") playing a game
in which the first user enters a number on the left hand side of the
screen. The second user enters a number on the right hand side of the
screen.

Both users should see what number is entered by the other user and the
sum of the two numbers displayed at the top of the screen.

- - - -

My "web server" is Webrick.

I think I know enough Ajax to make this happen if there were only one
tab. That is, if there were only a single "user" and the result was to
do nothing more than double what the user typed in.

I guess I'm lost as to what a "session" represents here.

Any guidance and explanations would be vastly appreciated here.

As should be clear from the post, above, I really don't understand how
the pieces fit together.

If Google were implemented in Rails, some controller would see the
request, process it, hand off to a view, and the view would render it.

Basic question: When the view is rendered and sent back to the client
browser, how does the browser know what tab to render?

The data with the response will come back over the same tcp connection
as the request, and that tcp connection is owned by some object that
knows what to do with the data (a bit more complicated if keep-alive &
pipelineing are involved but that sort of low level detail is probably
just handled by the networking library you sit on top of.

My "web server" is Webrick.

I think I know enough Ajax to make this happen if there were only one
tab. That is, if there were only a single "user" and the result was to
do nothing more than double what the user typed in.

I guess I'm lost as to what a "session" represents here.

One way of doing things might be for there to be a games table, and
pass the id of the game either in the url or stash it in the session
(session not so hot if this is actually going to be two tabs in the
same browser)

First of all, thank you about the info about the tcp connection. Can
you point me at any additional information about that, please?

One way of doing things might be for there to be a games table, and
pass the id of the game either in the url or stash it in the session
(session not so hot if this is actually going to be two tabs in the
same browser)

When on stores it in the session, where is that stored???

I am still very lost as to what a session is. Is there a good article
you could recommend?

Ralph

First of all, thank you about the info about the tcp connection. Can
you point me at any additional information about that, please?

Not that I can think of - it's just how people write network software

> One way of doing things might be for there to be a games table, and
> pass the id of the game either in the url or stash it in the session
> (session not so hot if this is actually going to be two tabs in the
> same browser)

When on stores it in the session, where is that stored???

I am still very lost as to what a session is. Is there a good article
you could recommend?

http://guides.rubyonrails.org/security.html#sessions

Fred

Frederick Cheung wrote:

First of all, thank you about the info about the tcp connection. �Can
you point me at any additional information about that, please?

Not that I can think of - it's just how people write network software

Yeah. If you need to think about the TCP connection when writing a
simple Web application, you've already made a design error.

> One way of doing things might be for there to be a games table, and
> pass the id of the game either in the url or stash it in the session
> (session not so hot if this is actually going to be two tabs in the
> same browser)

When on stores it in the session, where is that stored???

Configurable within Rails. Generally cookie or database table.

I am still very lost as to what a session is. �Is there a good article
you could recommend?

http://guides.rubyonrails.org/security.html#sessions

Rails generally does a good enough job of session management that you
can treat it as magic. Your automated tests will take care of the rest.

Fred

Best,

Marnen Laibow-Koser wrote:

Frederick Cheung wrote:

First of all, thank you about the info about the tcp connection. �Can
you point me at any additional information about that, please?

Not that I can think of - it's just how people write network software

Yeah. If you need to think about the TCP connection when writing a
simple Web application, you've already made a design error.

With luck, the game will be played by a lot of people.

What I want is for all the players to be seeing the same ... relatively
simple, screen.

And if any one of them makes a change then all of the players will see
the change.

In effect, I want to push data out when there is a change.

Am I thinking at the wrong level of abstraction?

Ralph Shnelvar wrote:

Marnen Laibow-Koser wrote:

Frederick Cheung wrote:

First of all, thank you about the info about the tcp connection. �Can
you point me at any additional information about that, please?

Not that I can think of - it's just how people write network software

Yeah. If you need to think about the TCP connection when writing a
simple Web application, you've already made a design error.

With luck, the game will be played by a lot of people.

What I want is for all the players to be seeing the same ... relatively
simple, screen.

And if any one of them makes a change then all of the players will see
the change.

In effect, I want to push data out when there is a change.

Am I thinking at the wrong level of abstraction?

Probably. Push is hard to impossible with Web technologies, unless you
use Java or maybe Flash. But you can certainly poll for updates with
Ajax, which is no different on the server side than just hitting
"reload" repeatedly in the browser.

Best,

Marnen Laibow-Koser wrote:

Probably. Push is hard to impossible with Web technologies, unless you
use Java or maybe Flash. But you can certainly poll for updates with
Ajax, which is no different on the server side than just hitting
"reload" repeatedly in the browser.

I had this idea ... tell me what's wrong with it.

On the client side:

(1) Whenever the user changes her data we issue an Ajax request to
update the data the server knows about.

(2) The client issues an asynchronous request (perhaps, an XHR) which
gets fulfilled when the server detects that there has been a change in
some player's data.

On the server side:

(3) The server waits for an Ajax request indicates that the client has
changed some data.

(4) The server then satisfies the request(s) made in (2).

I have no idea how to have the server sit on an unfulfilled Ajax (or any
other) request.

Ralph Shnelvar wrote:

Marnen Laibow-Koser wrote:

Probably. Push is hard to impossible with Web technologies, unless you
use Java or maybe Flash. But you can certainly poll for updates with
Ajax, which is no different on the server side than just hitting
"reload" repeatedly in the browser.

I had this idea ... tell me what's wrong with it.

On the client side:

(1) Whenever the user changes her data we issue an Ajax request to
update the data the server knows about.

Fine.

(2) The client issues an asynchronous request (perhaps, an XHR) which
gets fulfilled when the server detects that there has been a change in
some player's data.

Impossible. That means the server will block till it has new data, which
means the client will be stuck, waiting for a response from the server.

Or do you mean that the client simply polls periodically, and if the
server has no new data, it just says so?

On the server side:

(3) The server waits for an Ajax request indicates that the client has
changed some data.

Sure.

(4) The server then satisfies the request(s) made in (2).

...blocking the client until it does so.

I have no idea how to have the server sit on an unfulfilled Ajax (or any
other) request.

Good. You don't want to.

What you may be looking for is Comet (essentially Ajax over a persistent
HTTP connection), but that's really hard to do AFAIK.

Best,

(2) The client issues an asynchronous request (perhaps, an XHR) which
gets fulfilled when the server detects that there has been a change in
some player's data.

Impossible. That means the server will block till it has new data, which
means the client will be stuck, waiting for a response from the server.

Or do you mean that the client simply polls periodically, and if the
server has no new data, it just says so?

Why would the client block? It's an asynchronous request.

Isn't that the point of an asynchronous request ... not to block?

Ralph Shnelvar wrote:
> Marnen Laibow-Koser wrote:

> I have no idea how to have the server sit on an unfulfilled Ajax (or any
> other) request.

Good. You don't want to.

What you may be looking for is Comet (essentially Ajax over a persistent
HTTP connection), but that's really hard to do AFAIK.

You probably don't want to do it in rails but it's not too hard -
where I work we wrote a c++ daemon to handle long polling requests,
but there are already things like http://orbited.org/ or http://www.ape-project.org/
that handle the heavy lifting

Fred

Probably. Push is hard to impossible with Web technologies, unless you
use Java or maybe Flash. But you can certainly poll for updates with
Ajax, which is no different on the server side than just hitting
"reload" repeatedly in the browser.

I had this idea ... tell me what's wrong with it.

http://en.wikipedia.org/wiki/Web_Sockets

Regards,
Rimantas

Ralph Shnelvar wrote:

(2) The client issues an asynchronous request (perhaps, an XHR) which
gets fulfilled when the server detects that there has been a change in
some player's data.

Impossible. That means the server will block till it has new data, which
means the client will be stuck, waiting for a response from the server.

Or do you mean that the client simply polls periodically, and if the
server has no new data, it just says so?

Why would the client block? It's an asynchronous request.

Isn't that the point of an asynchronous request ... not to block?

You're right, my mistake.

However, there's one other thing you should be aware of. Unless
something has changed recently, most browsers allow only a fairly small
number of simultaneous HTTP connections. Having a persistent server
connection will tie up one of those slots.

Best,