server side calling client side

1 view
Skip to first unread message

thitoh

unread,
Jul 30, 2008, 3:54:30 PM7/30/08
to Google Web Toolkit
Hello, people!
To client side call functions in server side, I use RPC. But to server
side call funcions in client side, what I have to do?
Server side has an object X that has an attribute "status".
Client side has a label that shows the status of object X in server
side (The label call rpc that return the status of object X. The rpc
is called when user click button "refresh label").
See that user needs to click button "refresh label" to be sure that
the label is not wrong.
When status of Object X changes, the label changes only if user clicks
"refresh label".
I want to remove the button "refresh label" and when the state of
Object X changes, the label changes automaticly. How do I do it?

gregor

unread,
Jul 30, 2008, 8:53:36 PM7/30/08
to Google Web Toolkit
Hi Thitoh,

AFAIK there is no way you can get a server to fire an event in a
browser. There are two basic ways to accomplish what you want to do:

1) Polling: You put an RPC call in a repeat timer to check for state
changes on the server.
2) Blocking Request: You make a request to the server, the servlet
does not return a response immediately but goes into a permanent loop
until relevant state change occurs at which point it returns the
response. The client then sets up another request and so on.

You can Google these terms and you'll get full details about this. The
second approach is often known as comet. I believe that the blocking
request technique is thwart with problems and traps, so I would think
the polling approach is probably the better bet.

regards
gregor

walden

unread,
Jul 31, 2008, 8:35:04 AM7/31/08
to Google Web Toolkit
There's a third way you might also want to consider, possibly in
combination with the other two:

3) piggyback requests to refresh on other service requests, or trigger
refresh requests from unrelated UI events.

The idea here is that syncing an unwatched browser screen to a server
is a waste of resources. If the user isn't "gesturing", then she is
probably out to lunch or left for the day. If you want to get
sophisticated with this, you can use a combination of mouse movement
and elapsed time as criteria to trigger a refresh.

In most cases, "server push" is a greatly overrated technology.

Walden
> > Object X changes, the label changes automaticly. How do I do it?- Hide quoted text -
>
> - Show quoted text -

thitoh

unread,
Jul 31, 2008, 3:19:48 PM7/31/08
to Google Web Toolkit
Ok, Gregor and Walden!!!!!
I'll think about these ways!
Thanks a lot!!! :)

Kroc

unread,
Aug 1, 2008, 12:23:47 AM8/1/08
to Google Web Toolkit
If you need something 'perfect' you can also get rid of the http
limitation by using a java applet. Then, java and js can communicate
together.

By the way, it could be useful that gwt propose a way to simulate a
communication at server initiative by using one of the three
possibility mention above.
We can imagine that when a client service is called from server, the
request goes to a queue. Then, when server receives any request from
that client, server includes that request to the response.
Is it planed?

Vincent

thitoh

unread,
Aug 4, 2008, 1:26:47 PM8/4/08
to Google Web Toolkit
"If you need something 'perfect' you can also get rid of the http
limitation by using a java applet. Then, java and js can communicate
together"
Where I find something about it?

Vincent Legendre

unread,
Aug 4, 2008, 6:19:15 PM8/4/08
to Google-We...@googlegroups.com
I don't have my documentation with me, but a quick google research can lead to this kind of url:
http://java.sun.com/products/plugin/1.3/docs/jsobject.html

It's a netscape package, but it work with IE too.
When I was looking for this, I've found a lot of other example, so, help yourself :-)

Vincent

2008/8/5 thitoh <thiagosala...@gmail.com>

Przemek Gomulka

unread,
Aug 5, 2008, 2:00:48 AM8/5/08
to Google Web Toolkit
yo gregor
>2) Blocking Request: You make a request to the server, the servlet
>does not return a response immediately but goes into a permanent loop
>until relevant state change occurs at which point it returns the
>response. The client then sets up another request and so on.

is there any place, that i can read about how long browser can wait
for that reply?
does it play any role in this case? or rather browser can wait
infinitely long?
what other traps should i expect?

Przemek
Message has been deleted

gregor

unread,
Aug 5, 2008, 6:57:02 PM8/5/08
to Google Web Toolkit
Actually I think the method is a bit more sophisticated than I said in
that the connection is actually held open for as long as the client
wants it to and the server streams data up as and when a server event
occurs. That fits in well with Walden's comments on this and other
posts re: detecting user is out to lunch so close down connection and
re-establish when they get back (i.e. do something with mouse/
keyboard). Couple of learned links on the subject:

http://www.pushlets.com/doc/whitepaper.html
http://svn.xantus.org/shortbus/trunk/bayeux/bayeux.html

There are I believe a lot of problems with this, the most obvious
being:

1) The open connections seriously eat up server resources (much more
so that e.g. a straight polling option)
2) One of the two available connections supported by most browsers is
permanently in use
3) Any intermediate severs, such as proxy servers, may prove
uncooperative or even obstinate

regards
gregor
Reply all
Reply to author
Forward
0 new messages