Update included files without refresh

[Camron]

Hello,

I was wondering if it's possible to update a included file every 1-5 seconds without actually refreshing the entire thing. I am developing a simple chat script, which needs to update the file which contains the chat text (will be flat file). The frame needs to update to the latest text file so that all parties can see what has been stored.

I googled around but could not come up with anything that would help me (I tried many possibilities). I am assuming I would need to use javascript, in which case I am no javascript guru, so if someone could kindly let me know how this would be done, it would be greatly appreciated.

Thanks,
Camron

 

[cef]

Add a refresh header to the html code of the frame you want refreshed.

For example, if you want the frame containing the chat text to refresh every five seconds, put this in the header section of the frame's html file:

<META HTTP-EQUIV="Refresh" CONTENT="5; URL=http://this/file/name">

 

[weblord]

have you tried this one? though it uses mysql
http://ajaxchat.org/

 

[Camron]

Add a refresh header to the html code of the frame you want refreshed.

For example, if you want the frame containing the chat text to refresh every five seconds, put this in the header section of the frame's html file:

<META HTTP-EQUIV="Refresh" CONTENT="5; URL=http://this/file/name">

Actually, this is exactly not what I am looking for. I'm looking for something that is actually not refreshing rather than re-loading the include, because if I were to refresh that much my server would detect it as DDoS

have you tried this one? though it uses mysql
http://ajaxchat.org/

I need to create my own because there are some features that I must have (this will be used as a live support system rather than an open public chatroom).

 

[beaver6813]

Presuming you have some experience in coding i would reccomend ajax for this, so basically it will update a DIV every x seconds. This can be achived the most easily using a library like Prototype, and using the PeriodicalUpdater function.

Prototype:http://www.prototypejs.org/
http://www.prototypejs.org/api/ajax click Periodical Updater on the side, so as i said it will get the info from a file every x amount of seconds and put that into the div.

 

[weblord]

now i see the purpose, why host it on your server when you can do remote hosting?
and besides if server is down, you can't use it at all for support.

have you tried the possibilities of this?
http://www.kayako.com/

http://humanclick.com/ < - the server is you, the client is downloaded by your client
http://www.providesupport.com/
http://www.zazachat.com/
it will not consume your bandwidth and will not be treated as ddos since they refresh a lot.
or free http://www.livehelpengine.com/
HTH

 

[Camron]

now i see the purpose, why host it on your server when you can do remote hosting?
and besides if server is down, you can't use it at all for support.

have you tried the possibilities of this?
http://www.kayako.com/

http://humanclick.com/ < - the server is you, the client is downloaded by your client
http://www.providesupport.com/
http://www.zazachat.com/
it will not consume your bandwidth and will not be treated as ddos since they refresh a lot.

Thanks, but I am actually looking to use this script to sell as well as use it, plus I will be able to customize it in many ways.

Presuming you have some experience in coding i would reccomend ajax for this, so basically it will update a DIV every x seconds. This can be achived the most easily using a library like Prototype, and using the PeriodicalUpdater function.

Prototype:http://www.prototypejs.org/
http://www.prototypejs.org/api/ajax click Periodical Updater on the side, so as i said it will get the info from a file every x amount of seconds and put that into the div.

Looks interesting. Thanks for the link, I will check that out.

 

[beaver6813]

now i see the purpose, why host it on your server when you can do remote hosting?
and besides if server is down, you can't use it at all for support.

have you tried the possibilities of this?
http://www.kayako.com/

http://humanclick.com/ < - the server is you, the client is downloaded by your client
http://www.providesupport.com/
http://www.zazachat.com/
it will not consume your bandwidth and will not be treated as ddos since they refresh a lot.

Thanks, but I am actually looking to use this script to sell as well as use it, plus I will be able to customize it in many ways.

You should be able to sell the script with Prototype as long as you give the appropriate credit in the source files where it's used.

 

[Camron]

True, actually looking at Prototype, it looks like it actually has to be installed on the server before use. I was actually looking for something stand-alone.

 

[Jim_]

lol. Prototype does not need to be installed on the server. It is just plain JavaScript source code. You just have to load it in your browser like this:

<script src="prototype.js" type="text/javascript"></script>

and then you're set to use it's methods in your JavaScript.

 

[tm]

Definately an Ajax thing you need... this can't be achieved purely in PHP.

 

[cef]

Just so you know, whether you use ajax or a refresh header, it's the same to your server: an http request. As such, it could be interpreted as a ddos either way.

Ajax does it behind the scenes so that your page doesn't flicker on update. As you hinted in your first post, you're already using frames (at least it sounds like you are), which has the same visual result for the user: no flicker on update, because only the data in a frame is being refreshed.

That said, ajax is the "more modern" way of doing things, and because you want to market the script, is a more apporpriate implementation.

Bottom line though, your code has to call some server somewhere via http. If you want the calls to avoid being treated as a ddos attack, you have a few choices, each with some pros and cons.

For example, you could have apache (or better yet, lighttpd) listen on an alternative port, and configure the listener to ONLY serve the chat text. You would then whitelist that server and port with your firewall and/or datacenter and/or whomever monitors these things. If someone really does try to ddos that particular port and server, you could simply nullroute the requests, a step you would ultimately have to take anyhow.

The downside to this is that it would require communications on a non-standard port, which means opening the port everywhere on your firewall chain (at least for the relevant IP) and requiring the same of your clients, which is, to me, something of a dealbreaker.

So...no easy solution I'm afraid, but at least you have some more info to work with.