I'm not currently trying to set up a server with Websockets. Eventually I will, but I first just want to see a short working example of websockets, connecting to a third party server.
I found a short example here: http://www.websockets.org/about.html and here http://blog.chromium.org/2009/12/web-sockets-now-available-in-google.html but couldn't get either of them to work.
Do you know where I can find a couple/few confirmed working client side examples of websockets? I believe websockets.org provides an echo address ws://websockets.org:8787 (so please don't tell me "just set up a server yourself!). Thanks!
phpwebsocket works quite well for me, takes 2 minutes to set up and start testing
jWebSocket is a custom implementation of web sockets but they're compatible with native browser web sockets and they have a number of demos available, including a really basic hello world and a chat client. Terrible framed website though, so you'll have to go there and click the links on the left side to get to the demos.
Related
I'm attempting to make a mail client that is HTML5/JS only where users would have to define their mail server and credentials.
I've surfed google leading to dead ends and figured that this is the next best place (or superuser.com).
I was thinking of using HTML5 WebSocket if I could to make the connection to the server but I don't know enough of smtp, imap, or pop3's architecture to understand how javascript could pass the args and perform what I want it to do.
PHP cannot be involved in this project otherwise I wouldn't be asking the question.
Any help in locating this would be fantastic.
Nothing is impossible. Except this.
In standard HTML or JavaScript, you can't make raw-socket connections, which is what you'd need to speak any of the protocols you've listed. The WebSocket API doesn't help you, because the server must also speak WebSockets, and mail servers don't. This is actually all a good thing, though. Imagine if you visited a random website and it telnetted to your home router, setting it on fire and burning down your house. That's what websites would be able to do if they could initiate plain TCP socket connections.
You have a few options I can think of, neither of which involves building a webpage. (And to be clear, you didn't say your project had to be a webpage; you merely said HTML/JS, so these are indeed legitimate options.)
First is something like node-webkit. As the readme says, "You can write native apps in HTML and Javascript with node-webkit." You'll still have to distribute it as a native app, because that's what it is.
Second is a Chrome app, specifically using the chrome.socket API. But have fun writing a TLS layer over those sockets, which you'll find is a requirement for almost any mail server these days. If you succeed in doing that, you'll be able to distribute your mail client in the Chrome Web Store, where I assure you an email client will be quite popular.
Third, write a webserver that operates locally, so your users will visit something like http://localhost:9999/mail in their browser. This will be a real pain to distribute, but you can use almost any technology you want.
I'm sure there's a fourth valid option, and someone else can chime in on that one.
Best of luck.
I'm planning to realize the following project and would be thankful if somebody could verfy my approach!
I want to establish a fully bidirectional wireless realtime communication between a smartphone (cross platform) and a embedded microcontroller running a webserver.
The webserver should provide data of the connected hardware in realtime e.g. temerature.
The smartphone should render these on screen and you should be able to configure the hardware e.g led color with the smartphone and save the config to the embedded webserver.
My first guess was to use HTML5 websockets but they aren't available on all platforms so I got inspired by XBMC, which uses JSON-RPC.
Just imagine a car stero system with bluetooth connected to a µC with webserver and wifi dongle.
My plan is to implement a webapp on the webserver which lets serves the purpose mentioned above. But the tricky part is to get the user to establish a bluetooth connection to the stereosystem because i looked up similar questions which say you can't access stuff like bluetooth on the smartphone with HTML5.
long story short, this is the current idea:
hardware -> µC -> webserver -> HTML5 Webapp-> WIFI -> Smartphone
communication via JSON RCP.
I would be highly thankful if somesone could give a statement to said idea and planned implementation because I never done this before!
Thanks guys!
We at muzzley, have developed a framework to simplify this process. We provide a way for your browser applications to communicate with smartphones. In the side of the smartphone you have widgets that are already done (gamepad, drawpad, switch, swipe, others) or you can build your own html based widget.
(disclaimer: i work for this project)
Most of the work is already done for what you want to do :)
Quick start here:
http://www.muzzley.com/documentation/quick-start.html
You can pull from github several examples here:
https://github.com/muzzley/muzzley-demos/
Lib for browser:
http://www.muzzley.com/documentation/libraries/javascript.html
I hope it helps.
Best
I think your first instinct was probably right. Have you looked at socket.io for node? It's essentially a shiv which ensures that you can use websocket functionality in virtually any combination of device and browser (see list of supported transport mechanisms and browsers here).
It should allow you to avoid bluetooth altogether.
Well, A small idea of making an application ran through my mind. But this is the first time I would try to make an application. Till now I have worked on PHP, C++, Ruby with Rails frame work, but all at a beginner level.
I am ready to take a bigger leap and learn them extensively if my idea demands so. The requirement is such that the web app gives you a desktop notification. I have seen that happen with a Gmail chat box. All I need to know is, what could be right tools to start with? Does PHP go that far? Or working on Rails would be a better option? Also, is it possible for an average beginner level programmer to do such a thing? What all does it take to make an app like that?
The desktop notification is not language dependant. There is no server-side language that can make a notification appear on a desktop. It doesn't matter what you put on the server, you can't make that code put notifications on the desktop unless the client supports such a notification API.
Client support means there has to be some sort of application running on the client that can put up the notification dialog on the desktop. This is the number one requirement.
If you don't have anything running on the client with such support, then no matter what magic you put on the server (PHP, Ruby, Perl, ...) nothing will ever happen on the client.
That's why, as you see from the answer by KCiebiera, the clients that can make notifications possible are Chrome and Firefox.
What you do is run code on the client (Javascript in this case), that looks for something (a message from the server for example), and then instructs the browser (Chrome or Firefox), to launch the notification.
It's not more complicated than that. Look at the tutorial KCiebiera posted, and that should get you started.
Hope this helps you understand the problem better.
AFAIK desktop notifications are available only in Chrome/Chromium and Firefox browser. There is a working draft http://www.w3.org/TR/notifications/ and also a great tutorial http://www.html5rocks.com/en/tutorials/notifications/quick/ on how to use them. Basically you have to learn a JavaScript API.
What goes on the server-side is irrelevant here, as the notifications happen client-side. Desktop notifications are currently part of a W3C working draft, and are implemented in the current version of Chrome and the next release versions of Firefox, Safari, & IE; see the compatibility table for more details. There are plenty of tutorials out there on how to implement this.
You would have to implement on the server some method that the client-side can use to get (or be pushed) the notifications so that it can display them using the above mentioned API. It doesn't matter if your use Rails, PHP, C++, whatever, they can all do it with enough effort.
I was a big fan of AIM and live chat/buddy lists back in the day. With the rise of HTML5 and its use becoming more common in modern browsers, I'd like to develop an HTML5 messaging system.
What technologies do I have to look up? At the start, I won't care about the design (CSS), just functionality.
I'll most likely have a standard registration and store users in a MySQL Database.
Additionally, "friends" will also easily be stored in a database, populating a user's buddy list based on which user ID's he/she has marked as "friend".
The actual server and client connectivity is what most interests me. Is this technology available for HTML5 yet? Point me in the right direction and I'll be good to go!
For the chat, you would probably like to look in to Websockets (as you talk about HTML5).
There are also examples like this where NodeJS is used. To use node, you would have to run a node-server. For examples and more info: nodejs.org
I think the websockets API will be your first port of call for a messaging app in HTML5. You'll be wanting the server to notify the client rather than the client poll or rely on callbacks and this would be the start i think.
However, I don't think this is very well supported in even the most modern browser. In fact i believe firefox and opera have pulled support because of security concerns.
I haven't done any work in this myself but just though it looked interesting stuff. So I guess I just wish you luck with your dev. Exciting cutting edge stuff I think.
I really need your help with this. We are planning on developing a real-time web application. We look at different libraries and concepts and a little confused.
What we need is: clients connect to websites and send data(usually an integer + client machine name) whenever they want (usually 1-5 seconds). Also, the same clients must receive data(the data received from other clients) from the server in a real-time mode. (maximum 0.5 seconds). Also, this data must be stored in the database.
We were thinking about using different technologies, but cannot decide which one to use.
We need this web application to be supported on Iphones and Android Phones (maybe blackberry).
and, of course desktop browsers.
Pooling seems not a very good Idea in this situation, due to highloads.
Html 5 web sockets kinda new, and probably not supported by all browsers.
Have anyone used nodejs ?
or twisted matrix: http://twistedmatrix.com/trac/?
or orbited(cannot post more than one link)?
or tornado?
Or XMPP(Jabber. I did not find good examples.)?
or something else?
What technology is the best to use in this type of project? Also, we would probably prefer the technology that has some community support and free to use.
Thanks a lot!
There is a lot of things to consider here. I would say that HTML 5 is not an option, simply due to support across platform.
Running with NodeJS is most likely possible, but the communication methods are really complicated. Pushing data to a page isn't really something that HTML/web apps are designed to do....
To get a valid answer you are going to need to get someone to come in and sit with you to really iron out details and implementation.
When you say that clients "connect to a website", do you really need it to be a website? It sounds like all the client is sending is a number and for that you don't need a website. Just pick the language of your choice, open up a socket, and go from there.
Are you streaming data to be visualized? You might want to take a look at graphite (and/or "pyped" which is part of graphite).
What kind of data? What is the purpose?
For real-time you're not going to get a web site unless you use some type of RIA but even then, it isn't going to be enough. Services aren't going to be good enough either. You're going to end up doing some type of polling which will only ever be psuedo-real-time unless you do duplex mode which wont be supported on most of the platforms you want to support.
sockets are the way to go but that requires a client for each platform you want to handle. Maybe you should rethink your requirements.