What language should I use for a chat app

shant93

Member
Messages
119
Reaction score
0
Points
16
I want to try out an idea I had for a slightly different chat app, but before doing that I have to be able to write a basic chat app. hat I want to know is what language is the best suited for real-time updates across the internet on the same webpage, to send the information from the page and receive and display it on the other.

I realize that I should probably be using an offline interface, like a .exe, but I want to test it out in a browser-scripted method first, to see how people find the experience before forcing them to install apps.

Thanks,
Shant.

-----
Edit: Also, what an't I do if I want to respect the ToS involving instant-update scripts?
(ThIS should be relatively limited, maybe a dozen users, unless a friend thinks it's awesome and spreads it or something...)
 
Last edited:

lemon-tree

x10 Minion
Community Support
Messages
1,420
Reaction score
46
Points
48
The best combination is most likely to be PHP and Javascript through AJAX requests. It is not currently possible to do direct peer-to-peer within the browser without either using a intermediate server or using something like Java.
If you are trying to learn, look at how others have done it and take inspiration from them.
Just a quick note, if you plan to try to host the chat script on the free server here then you will be suspended.
 

shant93

Member
Messages
119
Reaction score
0
Points
16
In that case, where would one find examples of scripts, not just chat scripts?
 

Pyker

New Member
Messages
47
Reaction score
0
Points
0
Also, what an't I do if I want to respect the ToS involving instant-update scripts?
(ThIS should be relatively limited, maybe a dozen users, unless a friend thinks it's awesome and spreads it or something...)

Those type of scripts are forbidden because they spend too many resources. I think you should ask a member of the x10 Staff before attempting to put it online.
 

Bigbucks2528

New Member
Messages
69
Reaction score
1
Points
0
Maybe a shoutbox that refreshes ever minute or two might be best, they are not so bad!
 

callumacrae

not alex mac
Community Support
Messages
5,257
Reaction score
97
Points
48
Maybe a shoutbox that refreshes ever minute or two might be best, they are not so bad!

Ask a higher up in IRC, I suspect a shoutbox that refreshes every minute or two will be fine. Although slightly pointless.

~Callum
 

shant93

Member
Messages
119
Reaction score
0
Points
16
So basically, there is no way I am doing this online, unless a find another host... Anyways, One part of the concept was actually seeing what the other was typing. Any suggestions about how this could happen without hogging ressources (in broswer or not)
 

callumacrae

not alex mac
Community Support
Messages
5,257
Reaction score
97
Points
48
If you really wanted to do this you could upgrade to premium or get vps, but it's not possible on free.

~Callum
 

misson

Community Paragon
Community Support
Messages
2,572
Reaction score
72
Points
48
That Java suggestion (or Flash/Flex) is probably the best option for chat clients--no need to install anything, though it would also be easy to make an installable version (for Flash or Flex, you can create an AIR app), and both can more readily support push and peer-to-peer communication. PHP and JS are pretty much pull, which isn't so great for realtime chatting, and client-server. A standalone client could use multicasting for cheap 'n' easy peer communication. Java applets can't use multicast sockets, so they would either need separate connections to each peer or you'd need to stick to a client-server architecture. Multicasting with Flash and Flex is possible with Flash 10.1 and higher. The advantage of Java over Flash/Flex is that more platforms support Java.

A chat server would be simple enough. For peer-to-peer clients, it would publish multicast or client addresses for a given chat when queried, so that a client could join a chat by joining the multicast group or connecting to the other clients. For a client-server architecture, it would echo any received chat message to the other clients. With either architecture, you might want an authentication and authorization system.

The main problem on the free hosts is that you're not allowed to run your own servers. Another approach would be to use X10 to hold a catalog of chat servers, so that you could run a server on your own computer (or anywhere, for that matter) and clients could use the catalog on X10 to find chat servers. A chat server would inform the catalog whenever its IP changes. Besides using a catalog or getting a VPS account, another option is to sign up with a dynamic DNS service and solely use your own computers to run the chat server.
 

essellar

Community Advocate
Community Support
Messages
3,295
Reaction score
227
Points
63
There is another option that will allow you to run a chat on free hosting, and that's to host the chat on a separate server. I'm thinking specifically about app-oriented hosts like Google App Engine or CouchIO, which have free accounts (that you can make billable if you app is successful and needs more power and scalability) and less-restrictive hit/resource provisions as well as schemaless database back-ends that are better suited to text interchange than a relational database is.

That will raise a couple of problems, though, that you wouldn't have on a single paid hosting account. The first is that you'll definitely have to learn a new way of doing things. Google's App Engine means coding in Python or a Java Virtual Machine (JVM) language like Java, Rhino or Clojure. CouchDB applications are coded in JavaScript. And forget anything you might have thought you knew about databases -- relational DBs and SQL are only one approach (and not always the best approach) and neither of the hosts I've mentioned uses a SQL database. Then you have to worry about separate authentication if your HTML/PHP app is authenticated -- you don't want to force the user to log in twice, but you don't want to leave the chat channels unprotected either and you can't leave usernames and passwords floating around free in the HTTP stream.

So why not build the entire thing on an alternate host? Go for it -- if your site is otherwise very simple, or if you can take the time it requires to learn the systems well enough to create complex HTML apps. Let's face it -- PHP is the easy way out for a predominantly HTML-based application. Creating something that just responds to requests for JSON or XML data is relatively simple, and you don't have to worry about the way engine X saves and accesses resource files, etc.

It's a trade-off. Money for hosting against thought, planning and execution. Budget against ability. If you are close to the edge on money, but think you have a good idea that can solve that little issue (you know, like making the next Facebook-scale app), then it'll be worth the effort but not worth the gamble (most start-ups, like most restaurants, will fail). When the site begins to make money, you can scale up to meet the demand. If you are looking at a forever-restricted audience (a private friends-and-family app), then spend the five or ten bucks a month or whatever it'll cost to get the hosting plan you need and be satisfied that it's less than a phone bill.
 

shant93

Member
Messages
119
Reaction score
0
Points
16
Thanks for your suggestions guys, I hadn't really thought of the possibility of giants like Google offering such services. I was planning on learning Java anyways, so this can wait. It was just to test an interface, it's not worth any investment.
 
Top