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?

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?

Securing Rails Applications — Ruby on Rails Guides

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.

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,