«

I have two pages
one.html
two.html

page one.html
have a form named form1 and a textarea named text1
man one write in the textarea text 1

page two.html
have a form named form2 and a textarea named text2
man two read in the textarea text 2

The pages aren't in the same domain.
I want, if is possible, that the page two.html show in the textarea
text 2 that a man one write in the textarea text 1 in realtime (like
onkeyup)
Is like a chat but not a chat. The man one not have to submit the
form.
Thanks
Regards

pt36 wrote:
> I have two pages
> one.html
> two.html
>
> page one.html
> have a form named form1 and a textarea named text1
> man one write in the textarea text 1
>
> page two.html
> have a form named form2 and a textarea named text2
> man two read in the textarea text 2
>
> The pages aren't in the same domain.
> I want, if is possible, that the page two.html show in the textarea
> text 2 that a man one write in the textarea text 1 in realtime (like
> onkeyup)
> Is like a chat but not a chat. The man one not have to submit the
> form.
> Thanks
> Regards
>

Hi,

I think you'll have to make a trip via a server.
Two servers actually if they are in different domains.
If the domains are on the same physical server, you'll only need 1 of
course.

So some serverside coding is needed, eg in PHP or Perl.

It is easy to send the data typed in text1 to a server, server1, (with
keyup-event) via some AJAXOID solution.

It will be harder to keep form2 up to date, because it has to pull the
new data from server1, via server2.

Server2 talks with server1 to get the data in.

Can be done, but you'll have to poll server2 a lot to get a fast
response in text2.

Personally I think this is quite a horrible solution, since you create a
lot of serverload on both the servers.
Server1 gets a lot of AJAX requests in to update each letter that is
typed (keyup event).
Server2 will be busy because the javascript in the page with form2 is
polling the server every second or so.

You might consider a different technology, Java eg.

Regards,
Erwin Moller

Safalra wrote:
> On Fri, 28 Sep 2007 11:06:16 +0200, Erwin Moller wrote:
>> pt36 wrote:
>>> [...]
>>> I want, if is possible, that the page two.html show in the textarea
>>> text 2 that a man one write in the textarea text 1 in realtime (like
>>> onkeyup)
>>> [...]
>> I think you'll have to make a trip via a server.
>> Two servers actually if they are in different domains.
>> [...]
>> Can be done, but you'll have to poll server2 a lot to get a fast
>> response in text2.
>> [...]
>> Server2 will be busy because the javascript in the page with form2 is
>> polling the server every second or so.
>
>
> It might be more efficient for Server2 to delay responding until there is
> data to send to form2, subject to some maximum delay to avoid timeout. If
> there is no new data most of the time (that is, the user of form1 isn't
> typing most of them time), this will dramatically reduce the number of
> server requests made. This will of course require careful implementation of
> the server-side code to avoid it locking up the server.
>

Absolutely true.
Good improvement.

Regards,
Erwin Moller

Safalra wrote:

> On Fri, 28 Sep 2007 11:06:16 +0200, Erwin Moller wrote:
> > pt36 wrote:
> >> [...]
> >> I want, if is possible, that the page two.html show in the textarea
> >> text 2 that a man one write in the textarea text 1 in realtime (like
> >> onkeyup)
> >> [...]
>
> > I think you'll have to make a trip via a server.
> > Two servers actually if they are in different domains.
> > [...]
> > Can be done, but you'll have to poll server2 a lot to get a fast
> > response in text2.
> > [...]
> > Server2 will be busy because the javascript in the page with form2 is
> > polling the server every second or so.
>
> It might be more efficient for Server2 to delay responding until there is
> data to send to form2, subject to some maximum delay to avoid timeout. If
> there is no new data most of the time (that is, the user of form1 isn't
> typing most of them time), this will dramatically reduce the number of
> server requests made.

I don't think this would be a wise strategy, because Form2 cannot know
when Man1 types. Form2 needs to go to server anyway to check whether
the data has updated (that is, Man2 needs to initiate every request).

If Man2 fires this request and no data has updated, then you could
indeed delay the response for e.g. 20 seconds; but Man1 can type
something new during those 20 seconds, which can then only be shown to
Man2 after 20 seconds (at the following request that Man2 fires).

A one-second delay of Man2 would seem reasonable to me.

> This will of course require careful implementation of
> the server-side code to avoid it locking up the server.

The load on server is indeed very high in such scenarios; I think it's
better to use Java like Erwin suggested. Or Flash.

--
Bart

On 28 Sep, 10:06, Erwin Moller
<Since_humans_read_this_I_am_spammed_too_m...@spam yourself.com> wrote:
> pt36 wrote:
> > I have two pages
> > one.html
> > two.html
>
> > page one.html
> > have a form named form1 and a textarea named text1
> > man one write in the textarea text 1
>
> > page two.html
> > have a form named form2 and a textarea named text2
> > man two read in the textarea text 2
>
> > The pages aren't in the same domain.
> > I want, if is possible, that the page two.html show in the textarea
> > text 2 that a man one write in the textarea text 1 in realtime (like
> > onkeyup)
> > Is like a chat but not a chat. The man one not have to submit the
> > form.
> > Thanks
> > Regards
>
> Hi,
>
> I think you'll have to make a trip via a server.
> Two servers actually if they are in different domains.
> If the domains are on the same physical server, you'll only need 1 of
> course.
>
> So some serverside coding is needed, eg in PHP or Perl.
>
> It is easy to send the data typed in text1 to a server, server1, (with
> keyup-event) via some AJAXOID solution.
>
> It will be harder to keep form2 up to date, because it has to pull the
> new data from server1, via server2.
>
> Server2 talks with server1 to get the data in.
>
> Can be done, but you'll have to poll server2 a lot to get a fast
> response in text2.
>
> Personally I think this is quite a horrible solution, since you create a
> lot of serverload on both the servers.
> Server1 gets a lot of AJAX requests in to update each letter that is
> typed (keyup event).
> Server2 will be busy because the javascript in the page with form2 is
> polling the server every second or so.
>
> You might consider a different technology, Java eg.
>
> Regards,
> Erwin Moller- Hide quoted text -
>
> - Show quoted text -

As a matter of interest, how does Google Talk in the GoogleMail
browser window handle this? It give indication that the otehr party is
typing a message and then delivers it when it is complete?

Safalra wrote:

> On Fri, 28 Sep 2007 06:11:46 -0700, Bart Van der Donck wrote:
>
> > Safalra wrote:
>
> >> On Fri, 28 Sep 2007 11:06:16 +0200, Erwin Moller wrote:
> >>> pt36 wrote:
> >>>> [...]
> >>>> I want, if is possible, that the page two.html show in the textarea
> >>>> text 2 that a man one write in the textarea text 1 in realtime (like
> >>>> onkeyup)
> >>>> [...]
>
> >>> I think you'll have to make a trip via a server.
> >>> Two servers actually if they are in different domains.
> >>> [...]
> >>> Can be done, but you'll have to poll server2 a lot to get a fast
> >>> response in text2.
> >>> [...]
> >>> Server2 will be busy because the javascript in the page with form2 is
> >>> polling the server every second or so.
>
> >> It might be more efficient for Server2 to delay responding until there is
> >> data to send to form2, subject to some maximum delay to avoid timeout. If
> >> there is no new data most of the time (that is, the user of form1 isn't
> >> typing most of them time), this will dramatically reduce the number of
> >> server requests made.
>
> > I don't think this would be a wise strategy, because Form2 cannot know
> > when Man1 types. Form2 needs to go to server anyway to check whether
> > the data has updated (that is, Man2 needs to initiate every request).
>
> > If Man2 fires this request and no data has updated, then you could
> > indeed delay the response for e.g. 20 seconds; but Man1 can type
> > something new during those 20 seconds, which can then only be shown to
> > Man2 after 20 seconds (at the following request that Man2 fires).
>
> You've misundertood what I mean. Form2 will know when Man1 types, because
> as soon as Man1 types the server is informed and then responds to Form2.
> Permit me to explain with two examples:
>
> If Man1 isn't typing:
>
> - Form2 makes a server request
> - Nothing happens for 20 seconds
> - The server responds to Form2, saying nothing has happened
> - Form2 makes another server request
> - ...and so on
>
> If Man1 is typing:
>
> - Form2 makes a server request
> - Nothing happens for a bit
> - Form1 makes a server request sending new data
> - The server responds to Form2, with the new data
> - Form2 makes another server request
> - ...and so on

Ah, now I see it better. Yes I believe this would be a good plan, by
disabling the output buffer of the server script and let it run for 20
seconds (having its own sub-interval of 1 second or so).

> Form2 is constanly in communication with the server, but if Man1 isn't
> typing then the server only responds every 20 seconds, saying that nothing
> has happened. If Man1 is typing, the server responds as soon as it receives
> input (although to avoid heavy server load when Man1 is typing it shouldn't
> respond to Form2 until some amount of time after the request was made - one
> second, for example). The only tricky part is writing server-side code that
> doesn't lock up the server while waiting to see if new data arrives from
> Form1

I don't think this should be tricky - I'm quite familiar with these
kinds of constructions:

Preparation: investigate how much time-out is allowed for the CGI

Script actions:
(1) disable output buffer of script
(2) check if writable file has been updated by Man1
- if yes, respond with new content to Man2
- if no, send negative flag to Man2, sleep 1 second and
perform (2) twenty times in total
(3) new request from Man2: back to (1)

Man1 should then update the content with an onKeyUp event. I think
there should also be a limit on the (allowed number of) characters in
Man1's textarea, and always check for nicely terminated requests/
responses.

I remember using Netscape's Server Push about 10-15 years ago for this
kind of applications. It would be ideal here, but it's not supported
anymore. Anyway, Java still better

--
Bart

Bart Van der Donck wrote:

> Script actions:
> (1) disable output buffer of script
> (2) check if writable file has been updated by Man1
> - if yes, respond with new content to Man2
> - if no, send negative flag to Man2, sleep 1 second and
> perform (2) twenty times in total

Even better (and now I fully see your plan, I think):

- if no, send nothing to Man2, sleep 1 second internally
and keep checking when the contents of writable file has
changed, then only output to Man2 when it has actually
changed and close connection afterwards

--
Bart