Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #4975 > unrolled thread

chat on web, Ajax ?

Back to article view | Back to comp.lang.php

Contents

  chat on web, Ajax ? "sl@exabyte" <sb5309@hotmail.com> - 2012-02-24 21:59 +0800
    Re: chat on web, Ajax ? "sl@exabyte" <sb5309@hotmail.com> - 2012-02-24 22:15 +0800
      Re: chat on web, Ajax ? Captain Paralytic <paul_lautman@yahoo.com> - 2012-02-24 06:20 -0800
        Re: chat on web, Ajax ? "SL" <sb5309@hotmail.com> - 2012-02-24 23:52 +0800
          Re: chat on web, Ajax ? The Natural Philosopher <tnp@invalid.invalid> - 2012-02-24 15:59 +0000
            Re: chat on web, Ajax ? "SL" <sb5309@hotmail.com> - 2012-02-25 00:23 +0800
              Re: chat on web, Ajax ? Doug Miller <doug_at_milmac_dot_com@example.com> - 2012-02-24 16:52 +0000
                Re: chat on web, Ajax ? "sl@exabyte" <sb5309@hotmail.com> - 2012-02-25 10:01 +0800
      Re: chat on web, Ajax ? "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-02-24 16:22 +0100
    Re: chat on web, Ajax ? Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-02-24 15:28 +0100
      Re: chat on web, Ajax ? Tim Streater <timstreater@greenbee.net> - 2012-02-24 14:51 +0000
        Re: chat on web, Ajax ? The Natural Philosopher <tnp@invalid.invalid> - 2012-02-24 15:54 +0000
          Re: chat on web, Ajax ? Tim Streater <timstreater@greenbee.net> - 2012-02-24 19:02 +0000
            Re: chat on web, Ajax ? The Natural Philosopher <tnp@invalid.invalid> - 2012-02-24 21:06 +0000
              Re: chat on web, Ajax ? Tim Streater <timstreater@greenbee.net> - 2012-02-24 21:38 +0000
                Re: chat on web, Ajax ? The Natural Philosopher <tnp@invalid.invalid> - 2012-02-24 21:51 +0000
                  Re: chat on web, Ajax ? Tim Streater <timstreater@greenbee.net> - 2012-02-24 22:26 +0000
                    Re: chat on web, Ajax ? The Natural Philosopher <tnp@invalid.invalid> - 2012-02-25 13:15 +0000
                      Re: chat on web, Ajax ? Tim Streater <timstreater@greenbee.net> - 2012-02-25 13:20 +0000
                        Re: chat on web, Ajax ? The Natural Philosopher <tnp@invalid.invalid> - 2012-02-25 13:33 +0000
                          Re: chat on web, Ajax ? Tim Streater <timstreater@greenbee.net> - 2012-02-25 13:42 +0000
      Re: chat on web, Ajax ? "SL" <sb5309@hotmail.com> - 2012-02-25 00:31 +0800
    Re: chat on web, Ajax ? The Natural Philosopher <tnp@invalid.invalid> - 2012-02-24 15:48 +0000
    Re: chat on web, Ajax ? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-02-24 17:27 +0100
    Re: chat on web, Ajax ? Jeff North <jnorthau@yahoo.com.au> - 2012-02-26 00:13 +1100
    Re: chat on web, Ajax ? Arno Welzel <usenet@arnowelzel.de> - 2012-02-26 04:54 +0100

Page 1 of 2  [1] 2  Next page →

#4975 — chat on web, Ajax ?

Hi folks.

I thought I have gathered all pieces I need, then suddenly I realise there 
is still one problem.

I am implementing chat on the web, ie on a browse. On browser, I can only 
use javascript. So the problem is what method to use to listen for incoming 
data.

Ajax ? I am just wondering; Ajax does not seem to bother about port, I mean 
the standard method is "open socket at server, port 8888...".

Of course, when data is sent to a php file on server, it must be port 80.

Is this the only way on a browser ?

Thanks.

[toc] | [next] | [standalone]

#4976

> I thought I have gathered all pieces I need, then suddenly I realise
> there is still one problem.
>
> I am implementing chat on the web, ie on a browse. On browser, I can
> only use javascript. So the problem is what method to use to listen
> for incoming data.
>
> Ajax ? I am just wondering; Ajax does not seem to bother about port,
> I mean the standard method is "open socket at server, port 8888...".
>
> Of course, when data is sent to a php file on server, it must be port
> 80.
> Is this the only way on a browser ?
>

After reading some material, it seems that a timer (for Ajax) is necessary 
to pool the server for messages.

With java or C/C++, there is no timer, ie a client just listens on a socket, 
and it is notified once data is in. Correct me if I am wrong (ie the client 
does not pool the server in this case). 

[toc] | [prev] | [next] | [standalone]

#4978

On Feb 24, 2:15 pm, "sl@exabyte" <sb5...@hotmail.com> wrote:
> > I thought I have gathered all pieces I need, then suddenly I realise
> > there is still one problem.
>
> > I am implementing chat on the web, ie on a browse. On browser, I can
> > only use javascript. So the problem is what method to use to listen
> > for incoming data.
>
> > Ajax ? I am just wondering; Ajax does not seem to bother about port,
> > I mean the standard method is "open socket at server, port 8888...".
>
> > Of course, when data is sent to a php file on server, it must be port
> > 80.
> > Is this the only way on a browser ?
>
> After reading some material, it seems that a timer (for Ajax) is necessary
> to pool the server for messages.
>
> With java or C/C++, there is no timer, ie a client just listens on a socket,
> and it is notified once data is in. Correct me if I am wrong (ie the client
> does not pool the server in this case).

One has to ask, since there are so many already available free to
download, just why are you writing yet another one?

[toc] | [prev] | [next] | [standalone]

#4984

> One has to ask, since there are so many already available free to
> download, just why are you writing yet another one?

Sometimes history repeats. You see I trying to add other things to a chat, 
partly experimenting. So the first part is to learn.
Only after acquring the basics that I can move on.

Come to think of it, in school wheels often get re-invented. Of course there 
is no need to re-invent the steam engine. :-) 

[toc] | [prev] | [next] | [standalone]

#4986

SL wrote:
>> One has to ask, since there are so many already available free to
>> download, just why are you writing yet another one?
> 
> Sometimes history repeats. You see I trying to add other things to a chat, 
> partly experimenting. So the first part is to learn.
> Only after acquring the basics that I can move on.
> 
> Come to think of it, in school wheels often get re-invented. Of course there 
> is no need to re-invent the steam engine. :-) 
> 
> 
Absolutely. I spent some time earlier this week writing a  C library 
that will do a simple SMTP send.. Why? because it took less time that 
trying to actually work out how to use one of the many libraries..

And I wanted the fastest slimmest code to run under cron..

[toc] | [prev] | [next] | [standalone]

#4987

> Absolutely. I spent some time earlier this week writing a  C library
> that will do a simple SMTP send.. Why? because it took less time that
> trying to actually work out how to use one of the many libraries..
>
> And I wanted the fastest slimmest code to run under cron..

Wow, that sounds interesting.

The one thing now I wish to dig deep is Linux and programming. I wish I have 
48 hours a day.

I heard that if we live in neptune, a year there is 165 years here. 

[toc] | [prev] | [next] | [standalone]

#4990

"SL" <sb5309@hotmail.com> wrote in news:ji8dih$bm8$1@news.albasani.net:

> 
> I heard that if we live in neptune, a year there is 165 years here. 

Just means you'll die at age 1/2.

[toc] | [prev] | [next] | [standalone]

#4999

>>
>> I heard that if we live in neptune, a year there is 165 years here.
>
> Just means you'll die at age 1/2.

This is off topic.

Time is very special, they say relative. There is a possibility that if a 
day (assumed) has 48 hours, that is the sun sets after 24 hours, our body 
will adjust to it. Meaning the body adjusts to a year, ie setting of the sun 
is 24 hours.

While human being still lives 90 years, but relative to the Earth, the time 
span is different. 

[toc] | [prev] | [next] | [standalone]

#4981

Am 24.02.2012 15:15, schrieb sl@exabyte:
>> I thought I have gathered all pieces I need, then suddenly I realise
>> there is still one problem.
>>
>> I am implementing chat on the web, ie on a browse. On browser, I can
>> only use javascript. So the problem is what method to use to listen
>> for incoming data.
>>
>> Ajax ? I am just wondering; Ajax does not seem to bother about port,
>> I mean the standard method is "open socket at server, port 8888...".
>>
>> Of course, when data is sent to a php file on server, it must be port
>> 80.
>> Is this the only way on a browser ?
>>
> 
> After reading some material, it seems that a timer (for Ajax) is necessary 
> to pool the server for messages.
> 
> With java or C/C++, there is no timer, ie a client just listens on a socket, 
> and it is notified once data is in. Correct me if I am wrong (ie the client 
> does not pool the server in this case). 
> 
> 

Replace "pool" by "poll" - a distorting typo...

/Str.

[toc] | [prev] | [next] | [standalone]

#4979

On 2/24/2012 2:59 PM, sl@exabyte wrote:
> Hi folks.

Hi again,


>
> I thought I have gathered all pieces I need, then suddenly I realise there
> is still one problem.

Some of us guessed by reading your former thread. :-)


>
> I am implementing chat on the web, ie on a browse. On browser, I can only
> use javascript. So the problem is what method to use to listen for incoming
> data.

Yes.
That is the problem: typical http requests data from some server, and 
after it arrives, that's it.
A normal http request:
1) Browser sends request to server.
2) server answers
the end.
How to let the browser listen to the server?

Short answer: You cannot. Not without some tricks or additional software 
(Java, Flash for example).

Read up here first:
http://en.wikipedia.org/wiki/Push_technology#HTTP_server_push

You can see on that page that a few experiments have been tried, but 
none of them if fully reliable.
For example: multipart/x-mixed-replace is not supported by IE, and I 
don't know about mobile devices.

You have 2 options:
1) Make a client-pull approach, eg with XHR ("Ajax").
http://en.wikipedia.org/wiki/XMLHttpRequest
Advantage: Easy to implement.
Drawback: All the connected clients will be sending update-requests all 
the time. This will lead to extra serverload which can kill the server 
if you have many clients trying to chat.

2) Use additional software that CAN listen.
Problem: See former thread: Suppose your server wants to PUSH new data 
to some client: How to deliver that behind a firewall/NAT? To which port?

Maybe IP6 and UPNP can help you out? I am not sure to be honest.
http://en.wikipedia.org/wiki/UPNP
UPNP can help you out of the NAT mess, but it isn't supported everywhere 
(I disabled it because I don't want programs to open ports on my router.)

I once created a chat application, and resorted to PULL technology 
because of all the problems. In my situation that was OK because the 
load was low, and the approach worked (This was before the XHR days, and 
I used a hidden frame and Javascript to pull the trick.)

Bottomline: Decide if you want to go CLIENT-PULL (easy, but limited) or 
SERVER-PUSH (Hard).

But you better go to a networking group instead of this one.
These advanced networking protocols (both IP6 and UPNP) are quite 
complex, and this isn't PHP related.

Regards,
Erwin Moller

>
> Ajax ? I am just wondering; Ajax does not seem to bother about port, I mean
> the standard method is "open socket at server, port 8888...".
>
> Of course, when data is sent to a php file on server, it must be port 80.
>
> Is this the only way on a browser ?
>
> Thanks.
>
>




-- 
"That which can be asserted without evidence, can be dismissed without 
evidence."
-- Christopher Hitchens

[toc] | [prev] | [next] | [standalone]

#4980

In article <4f479e77$0$6860$e4fe514c@news2.news.xs4all.nl>,
 Erwin Moller <erwinmollerusenet@xs4all.nl> wrote:

> On 2/24/2012 2:59 PM, sl@exabyte wrote:

> > I am implementing chat on the web, ie on a browse. On browser, I can only
> > use javascript. So the problem is what method to use to listen for incoming
> > data.
> 
> Yes.
> That is the problem: typical http requests data from some server, and 
> after it arrives, that's it.
> A normal http request:
> 1) Browser sends request to server.
> 2) server answers
> the end.
> How to let the browser listen to the server?
> 
> Short answer: You cannot. Not without some tricks or additional software 
> (Java, Flash for example).
> 
> Read up here first:
> http://en.wikipedia.org/wiki/Push_technology#HTTP_server_push
> 
> You can see on that page that a few experiments have been tried, but 
> none of them if fully reliable.
> For example: multipart/x-mixed-replace is not supported by IE, and I 
> don't know about mobile devices.
> 
> You have 2 options:
> 1) Make a client-pull approach, eg with XHR ("Ajax").
> http://en.wikipedia.org/wiki/XMLHttpRequest
> Advantage: Easy to implement.
> Drawback: All the connected clients will be sending update-requests all 
> the time. This will lead to extra serverload which can kill the server 
> if you have many clients trying to chat.
> 
> 2) Use additional software that CAN listen.
> Problem: See former thread: Suppose your server wants to PUSH new data 
> to some client: How to deliver that behind a firewall/NAT? To which port?
> 
> Maybe IP6 and UPNP can help you out? I am not sure to be honest.
> http://en.wikipedia.org/wiki/UPNP
> UPNP can help you out of the NAT mess, but it isn't supported everywhere 
> (I disabled it because I don't want programs to open ports on my router.)
> 
> I once created a chat application, and resorted to PULL technology 
> because of all the problems. In my situation that was OK because the 
> load was low, and the approach worked (This was before the XHR days, and 
> I used a hidden frame and Javascript to pull the trick.)
> 
> Bottomline: Decide if you want to go CLIENT-PULL (easy, but limited) or 
> SERVER-PUSH (Hard).
> 
> But you better go to a networking group instead of this one.
> These advanced networking protocols (both IP6 and UPNP) are quite 
> complex, and this isn't PHP related.

Or you can wait until websockets is more widely available - see RFC 6455:

<http://tools.ietf.org/html/rfc6455>

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#4985

Tim Streater wrote:

> 
> Or you can wait until websockets is more widely available - see RFC 6455:
> 
> <http://tools.ietf.org/html/rfc6455>
> 

Now that was worth a mention Tim.

Its an implementation the world badly needs, to do 'cloud' based' stuff.

In your OPPINION when is it likely to be something that apache and  most 
browsers understand..or is it even a browser issue at all?
.

[toc] | [prev] | [next] | [standalone]

#4992

In article <ji8brm$6k0$2@news.albasani.net>,
 The Natural Philosopher <tnp@invalid.invalid> wrote:

> Tim Streater wrote:
> 
> > Or you can wait until websockets is more widely available - see RFC 6455:
> > 
> > <http://tools.ietf.org/html/rfc6455>
> 
> Now that was worth a mention Tim.
> 
> Its an implementation the world badly needs, to do 'cloud' based' stuff.
> 
> In your OPINION when is it likely to be something that apache and  most 
> browsers understand..or is it even a browser issue at all?

Apache doesn't need to be involved, the browser can use it to 
communicate with any listening software. There've been a couple of 
iterations of the websockets handshake but looks now like its been 
finalised so we can hope that browsers soon implement the final spec.

Last year I was testing it for use with my email client, Safari 5.1 
implements it and I was able to find a listener (several in fact) 
written in PHP. I want this since at present I'm using AJAX to an 
instance of apache, but that's way too heavy for the app's actual needs.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#4994

Tim Streater wrote:
> In article <ji8brm$6k0$2@news.albasani.net>,
> The Natural Philosopher <tnp@invalid.invalid> wrote:
> 
>> Tim Streater wrote:
>>
>> > Or you can wait until websockets is more widely available - see RFC 
>> 6455:
>> > > <http://tools.ietf.org/html/rfc6455>
>>
>> Now that was worth a mention Tim.
>>
>> Its an implementation the world badly needs, to do 'cloud' based' stuff.
>>
>> In your OPINION when is it likely to be something that apache and  
>> most browsers understand..or is it even a browser issue at all?
> 
> Apache doesn't need to be involved, the browser can use it to 
> communicate with any listening software. There've been a couple of 
> iterations of the websockets handshake but looks now like its been 
> finalised so we can hope that browsers soon implement the final spec.
> 
> Last year I was testing it for use with my email client, Safari 5.1 
> implements it and I was able to find a listener (several in fact) 
> written in PHP. I want this since at present I'm using AJAX to an 
> instance of apache, but that's way too heavy for the app's actual needs.
> 

Great. But I suspect its going to be another massive security hole 
opened up ...:-(

[toc] | [prev] | [next] | [standalone]

#4995

In article <ji8u4c$f4n$2@news.albasani.net>,
 The Natural Philosopher <tnp@invalid.invalid> wrote:

> Tim Streater wrote:
> > In article <ji8brm$6k0$2@news.albasani.net>,
> > The Natural Philosopher <tnp@invalid.invalid> wrote:
> > 
> >> Tim Streater wrote:
> >>
> >> > Or you can wait until websockets is more widely available - see RFC 
> >> 6455:
> >> > > <http://tools.ietf.org/html/rfc6455>
> >>
> >> Now that was worth a mention Tim.
> >>
> >> Its an implementation the world badly needs, to do 'cloud' based' stuff.
> >>
> >> In your OPINION when is it likely to be something that apache and  
> >> most browsers understand..or is it even a browser issue at all?
> > 
> > Apache doesn't need to be involved, the browser can use it to 
> > communicate with any listening software. There've been a couple of 
> > iterations of the websockets handshake but looks now like its been 
> > finalised so we can hope that browsers soon implement the final spec.
> > 
> > Last year I was testing it for use with my email client, Safari 5.1 
> > implements it and I was able to find a listener (several in fact) 
> > written in PHP. I want this since at present I'm using AJAX to an 
> > instance of apache, but that's way too heavy for the app's actual needs.
> 
> Great. But I suspect its going to be another massive security hole 
> opened up ...:-(

Perhaps. In my case its all within localhost.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#4997

Tim Streater wrote:
> In article <ji8u4c$f4n$2@news.albasani.net>,
> The Natural Philosopher <tnp@invalid.invalid> wrote:
> 
>> Tim Streater wrote:
>> > In article <ji8brm$6k0$2@news.albasani.net>,
>> > The Natural Philosopher <tnp@invalid.invalid> wrote:
>> > >> Tim Streater wrote:
>> >>
>> >> > Or you can wait until websockets is more widely available - see 
>> RFC >> 6455:
>> >> > > <http://tools.ietf.org/html/rfc6455>
>> >>
>> >> Now that was worth a mention Tim.
>> >>
>> >> Its an implementation the world badly needs, to do 'cloud' based' 
>> stuff.
>> >>
>> >> In your OPINION when is it likely to be something that apache and  
>> >> most browsers understand..or is it even a browser issue at all?
>> > > Apache doesn't need to be involved, the browser can use it to > 
>> communicate with any listening software. There've been a couple of > 
>> iterations of the websockets handshake but looks now like its been > 
>> finalised so we can hope that browsers soon implement the final spec.
>> > > Last year I was testing it for use with my email client, Safari 
>> 5.1 > implements it and I was able to find a listener (several in 
>> fact) > written in PHP. I want this since at present I'm using AJAX to 
>> an > instance of apache, but that's way too heavy for the app's actual 
>> needs.
>>
>> Great. But I suspect its going to be another massive security hole 
>> opened up ...:-(
> 
> Perhaps. In my case its all within localhost.
> 
yes. The app I may use this on is all within my LAN.


Its seems firefox 10.0.2 is quite happy to websocket away.

Just needs a daemon for the server...inetd? yep that'll do..and a leetle 
teensy bit of code to be invoked by it.

Got any serverside cribs

All I found was this..

http://code.google.com/p/phpwebsocket/source/browse/trunk/%20phpwebsocket/server.php
?

[toc] | [prev] | [next] | [standalone]

#4998

In article <ji90od$k49$1@news.albasani.net>,
 The Natural Philosopher <tnp@invalid.invalid> wrote:

> Tim Streater wrote:
> > In article <ji8u4c$f4n$2@news.albasani.net>,
> > The Natural Philosopher <tnp@invalid.invalid> wrote:
> > 
> >> Tim Streater wrote:
> >> > In article <ji8brm$6k0$2@news.albasani.net>,
> >> > The Natural Philosopher <tnp@invalid.invalid> wrote:
> >> > >> Tim Streater wrote:
> >> >>
> >> >> > Or you can wait until websockets is more widely available - see 
> >> RFC >> 6455:
> >> >> > > <http://tools.ietf.org/html/rfc6455>
> >> >>
> >> >> Now that was worth a mention Tim.
> >> >>
> >> >> Its an implementation the world badly needs, to do 'cloud' based' 
> >> stuff.
> >> >>
> >> >> In your OPINION when is it likely to be something that apache and  
> >> >> most browsers understand..or is it even a browser issue at all?
> >> > > Apache doesn't need to be involved, the browser can use it to > 
> >> communicate with any listening software. There've been a couple of > 
> >> iterations of the websockets handshake but looks now like its been > 
> >> finalised so we can hope that browsers soon implement the final spec.
> >> > > Last year I was testing it for use with my email client, Safari 
> >> 5.1 > implements it and I was able to find a listener (several in 
> >> fact) > written in PHP. I want this since at present I'm using AJAX to 
> >> an > instance of apache, but that's way too heavy for the app's actual 
> >> needs.
> >>
> >> Great. But I suspect its going to be another massive security hole 
> >> opened up ...:-(
> > 
> > Perhaps. In my case its all within localhost.
> > 
> yes. The app I may use this on is all within my LAN.
> 
> Its seems firefox 10.0.2 is quite happy to websocket away.
> 
> Just needs a daemon for the server...inetd? yep that'll do..and a leetle 
> teensy bit of code to be invoked by it.
> 
> Got any serverside cribs
> 
> All I found was this..
> 
> http://code.google.com/p/phpwebsocket/source/browse/trunk/%20phpwebsocket/serv
> er.php
> ?

Could start here:

  <http://en.wikipedia.org/wiki/Comparison_of_WebSocket_implementations>

I did some tests with this one:

  <https://github.com/jam1401>

I also found something called daemonize that allows me to write a daemon 
as a PHP script but have it run as a proper background daemon.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#5002

Tim Streater wrote:
> In article <ji90od$k49$1@news.albasani.net>,
> The Natural Philosopher <tnp@invalid.invalid> wrote:
> 
>> Tim Streater wrote:
>> > In article <ji8u4c$f4n$2@news.albasani.net>,
>> > The Natural Philosopher <tnp@invalid.invalid> wrote:
>> > >> Tim Streater wrote:
>> >> > In article <ji8brm$6k0$2@news.albasani.net>,
>> >> > The Natural Philosopher <tnp@invalid.invalid> wrote:
>> >> > >> Tim Streater wrote:
>> >> >>
>> >> >> > Or you can wait until websockets is more widely available - 
>> see >> RFC >> 6455:
>> >> >> > > <http://tools.ietf.org/html/rfc6455>
>> >> >>
>> >> >> Now that was worth a mention Tim.
>> >> >>
>> >> >> Its an implementation the world badly needs, to do 'cloud' 
>> based' >> stuff.
>> >> >>
>> >> >> In your OPINION when is it likely to be something that apache 
>> and  >> >> most browsers understand..or is it even a browser issue at 
>> all?
>> >> > > Apache doesn't need to be involved, the browser can use it to > 
>> >> communicate with any listening software. There've been a couple of 
>> > >> iterations of the websockets handshake but looks now like its 
>> been > >> finalised so we can hope that browsers soon implement the 
>> final spec.
>> >> > > Last year I was testing it for use with my email client, Safari 
>> >> 5.1 > implements it and I was able to find a listener (several in 
>> >> fact) > written in PHP. I want this since at present I'm using AJAX 
>> to >> an > instance of apache, but that's way too heavy for the app's 
>> actual >> needs.
>> >>
>> >> Great. But I suspect its going to be another massive security hole 
>> >> opened up ...:-(
>> > > Perhaps. In my case its all within localhost.
>> > yes. The app I may use this on is all within my LAN.
>>
>> Its seems firefox 10.0.2 is quite happy to websocket away.
>>
>> Just needs a daemon for the server...inetd? yep that'll do..and a 
>> leetle teensy bit of code to be invoked by it.
>>
>> Got any serverside cribs
>>
>> All I found was this..
>>
>> http://code.google.com/p/phpwebsocket/source/browse/trunk/%20phpwebsocket/serv 
>>
>> er.php
>> ?
> 
> Could start here:
> 
>  <http://en.wikipedia.org/wiki/Comparison_of_WebSocket_implementations>
> 
> I did some tests with this one:
> 
>  <https://github.com/jam1401>
> 

that's worth a look..

> I also found something called daemonize that allows me to write a daemon 
> as a PHP script but have it run as a proper background daemon.
> 

well you can always attach a script to inetd..for low volume use.

And a C style daemon is not the worst programming job in the world..

I've been mixing C and PHP recently, and to be honest there is not a 
great deal of difference in coding time. And once you have a makefile 
source->binary for small projects is not much slower than saving a php 
file :-)

[toc] | [prev] | [next] | [standalone]

#5004

In article <jiamso$n31$1@news.albasani.net>,
 The Natural Philosopher <tnp@invalid.invalid> wrote:

> Tim Streater wrote:

> > I also found something called daemonize that allows me to write a daemon 
> > as a PHP script but have it run as a proper background daemon.

> well you can always attach a script to inetd..for low volume use.
> 
> And a C style daemon is not the worst programming job in the world..
> 
> I've been mixing C and PHP recently, and to be honest there is not a 
> great deal of difference in coding time. And once you have a makefile 
> source->binary for small projects is not much slower than saving a php 
> file :-)

Must be 20 years since I wrote any amount of C. Not sure I could be 
arsed to have another go at it (other than small mods to e.g. the 
sqlite3 command line tool). I'll stick to PHP, which seems fast enough 
for my purposes. Each time I've had a major bottleneck in my email 
client I've just rejigged either the PHP or the JavaScript and it's gone 
away.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#5005

Tim Streater wrote:
> In article <jiamso$n31$1@news.albasani.net>,
> The Natural Philosopher <tnp@invalid.invalid> wrote:
> 
>> Tim Streater wrote:
> 
>> > I also found something called daemonize that allows me to write a 
>> daemon > as a PHP script but have it run as a proper background daemon.
> 
>> well you can always attach a script to inetd..for low volume use.
>>
>> And a C style daemon is not the worst programming job in the world..
>>
>> I've been mixing C and PHP recently, and to be honest there is not a 
>> great deal of difference in coding time. And once you have a makefile 
>> source->binary for small projects is not much slower than saving a php 
>> file :-)
> 
> Must be 20 years since I wrote any amount of C.

well I was feeling like that too. It all came back fairly quickly, and I 
realised how much I missed PROPER strong typing..

  Not sure I could be
> arsed to have another go at it (other than small mods to e.g. the 
> sqlite3 command line tool). I'll stick to PHP, which seems fast enough 
> for my purposes. Each time I've had a major bottleneck in my email 
> client I've just rejigged either the PHP or the JavaScript and it's gone 
> away.
> 

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.php

csiph-web