I just found an interesting demo of what can be done with the cappuccino framework;
Push with Cappuccino and Tornado
As far as I understands it, It keeps an async client/server connection, which is great to keep a "content" updated.
I would like to know if there is any way I can do the same thing using JQuery or another library. Cappuccino looks a bit like a all-or-nothing framework.
What you are seeing there is not particular to cappucino or Tornado: its an example of HTTP long-polling to simulate async connections. Essentailly a client makes a request to the server with a very long (or infinite) timeout and the server responds when it has some data.
It's a workaround for the fact that until very recently there was no way for a browser to receive a request from a web-server. This is changing as the most recent web-standards are gaining adoption.
In short, there is nothing to stop you employing this kind of technique in any framework. Take a look at the wikipedia page on Comet for more info.
In your specific case, you might find the answers on this question helpful as they are specific to jQuery.
Related
I am curious How to dynamically update field without refresh and without killing the server with queries? Stackoverflow has this functionality when someone answer our question it indicates on the top of the page but my question is : Is this based on ajax and Jquery
setInterval();
function or there is another way? I can imagine how many visits has this website per day and if setInterval() is made to send ajax request to the server each 10sec for example I think this will kill the server.. Am I wrong, is there another smart way that saves server performance or even here is uset setInterval(); to alert users? In the console I don't see any ajax request running.. What I am missing? Thank you in advance for any suggestions or samples !
What you are looking for is a "push"-like technology. There are several ways to do it, Ajax being the most basic and the least preferred due to reasons you already mentioned. Long-polling, server sent events and web sockets are the other methods.
Popular libraries like Socket.io make it simple enough to get started, taking care of browser dependencies by choosing the right technology compatible with the browser.
This SO answer summarizes these technologies for you to get started. Or this article, and there are more if you search by these terms: long-polling, sse, websockets.
I am working on app where I need to pass messages between a C++ application and a Javascript web app.
Certainly I could write sockets code myself in either language and I have done this in the past when necessary.
What I would really like is a higher-level message posting or message queueing API that does a lot of the work for me. Does anyone know of such an API?
I have looked at ICE, and it doesn't appear to have Javascript bindings. I have also looked at Boost message queue, but it only caters for the C++ side of things. If necessary I might roll my own Javascript bindings for either of these technologies.
UPDATE: Sorry should have mentioned this before, I want to run this in a browser.
To give a more complete story what I want is a simple browser-based app that is used to configure and display logging for a C++ application.
I know there are other ways of doing this, but I am specifically interested in a high-level library in both C++ and browser-based Javascript that builds a message queue ontop of the sockets API (if there isn't one then I might consider implementing it myself and writing up a code project article).
ALSO: I'm not bothered about portability in terms of the web browser. Eg if there is a high-level IPC Javascript library that only works in Chrome, I'll be happy with that.
With JavaScript I assume that you are running it in a browser? In this case your C++ application needs to provide a webserver and some kind of JSON based webservice that you can call. On the JavaScript side you just use AJAX to communicate with that webservice.
An alternative would be websockets which might be a little harder to implement on the C++ side though.
To simply answer your question: No, there is no IPC implemented in ECMAscript out of the box.
But you actually answered you question already. If you try to communicate with Javascript that runs in a browser, you indeed should use (web-)sockets connections to pipe date in either direction. Of course you could write a simple HTTP server in C++, but I guess that is overkill and does not have the capabilitys of bi-directional sockets.
It's still some work to implement a web-socket connection in C++ from the scratch (the specs were in flux for a long time), but I guess there are some librarys out already.
If you're trying to communicate with node.js, this is an almost trivial task using real sockets/pipes.
I have found a solution that meets my needs. It isn't exactly perfect but I think it works well enough.
Some people suggested using HTTP and ajax. That turned out to be a useful idea and after some prototyping I think it solves my rather basic needs.
To be more specific I am using the Mongoose HTTP server embedded in my C++ application and I am using the jQuery ajax function to pull data from the server. The jQuery client polls the server continously for new data, not particularly efficient but I think it will do the job good enough for me.
Once my implementation is complete I'll write an article explaining how to do this in detail and then I'll update this answer.
You could try DBus, it has very simple mechanism to define, query and use interfaces, and there are some components for XPCOM and webkit based browsers (for example http://sandbox.movial.com/wiki/index.php/Browser_DBus_Bridge and http://code.google.com/p/v8-dbus/). Also DBus is opensource and cross platform.
For a server side or non-browser implementation how about named pipes?
Yes it's vintage technology and the usage depends which OS you use, but as long as your server side js environment has ability to read and write files it may work, and it fits the description 'high-level' inter-process communication.
I'm building a web app for 'brainstorming.' Here's how it works: essentially, a user can come onto the app, and submit a challenge, or click on one that's already there, then think up ideas to resolve that challenge and post them up. I hacked together a basic example here on couchdb: http://wamoyo.iriscouch.com/ideageneration/_design/IdeaGeneration/attachments%2findex.html
I'm going to rebuild it from scratch and all, and I'm hitting up against a challenge that's very unfamiliar to me. I'd like for multiple users to be able to generate ideas for the same challenge at the same time. Kinda like the way google docs allows multiple people to edit a shared document. I have some preliminary thoughts on how to go about this, but I thought I'd ask the expert network here.
I'm fairly comfortable with AJAX, is there a pure AJAX way to make it live and multiuser? Would there be an enormous benefit to going with node.js? What might be some other options?
Thanks soo much!
There are several approaches in making such web pages, using plain ajax polling, using long polling and using web sockets.
Ajax polling - easy to implement, essentially connecting to server recurrently via javascript timer, retrieve data from server and send it back via regular Ajax.
Advantages: easy to implement, works everywhere
Disadvantages: the updates are not in real-time, the data is exchanged only when the timer ticks.
Long polling - the idea is that the connection stays open until it times out, then the connection is reestablished. Can be tricky to implement because of different settings for request timeouts for different web servers, routers, etc.
Web sockets - part of HTML5 umbrella, works only in fairly modern browsers, the protocol changes often which may cause incompatibilities during development and production. Can be used natively with modern browsers and via a Flash plugin with older ones. This technology is most lightweight, because it doesn't incur all the HTTP overhead. Think of it as bi-directional, full-duplex communication channel between a browser and a web server via TCP.
For a detailed discussion, I recommend reading this good post by Scott Hanselman. It tells the story about SignalR, but is applicable to other server-side frameworks.
There is also a podcast by same author, the guest goes fairly deeply into explaining these technologies. Worth listening, IMO.
To answer your question about node.js, please share us your current server technology, so we could get more insight into your stack.
Could anyone that has used both share his/her experience? What are the main differences and which one do you prefer? Thank you.
Different socket.io vs APE:
socket.io is coded in javascript(node.js) while APE is coded in C. I believe that is a big difference when you want to contribute. Maybe because you like the project or maybe because you want some more functionality. I think it will be easier to contribute Socket.io because you program Javascript, which is easier to grasp according to a lot of people(I Agree, although C is also very cool language).
I believe socket.io supports a lot more browsers/transport compared to APE, but I am not sure. Socket.io information vs information from APE page:
APE Server is an Comet server
implementing the POST and GET methods
of the HTTP protocol. It does not
replace a regular Web Server (such as
Apache, Lighttpd or Nginx), however,
the APE Server is only used for AJAX
Push.
So I guess APE supports less transports then socket.io.
Like Raynos said it is difficult to compare those two products and I believe you should play with them both and then decide which one you like more.
Same Socket.io/APE:
You can both code in Javascript to communicate with the server. I think you will have more freedom using socket.io because everything is exposed via Javascript.
Experience:
I only have experience with socket.io and I like it a lot.
Having spent some time developing with Node.js, I can't say that APE appears to be better than node. Based on sheer popularity, it seems that Node.js is probably the developer's choice -- and node.js appears to be more versatile as well.
Node essentially is you making a full on HTTP or TCP/IP. So, all of the mime type handling, data buffering, response headers, and server side routing are all things you'll have to do with your code. Node does streaming as well. I'm not sure about whether this is considered less problematic than normal ajax long polling at this point.
After googling around, I've found that people consider APE to be more of just a plain ol' push server, in which comet functionality is already there to be consumed, rather than Node, which would have you write your own. Don't be afraid of the prospect of writing things out with node though, they've got a very thorough documentation, and their methods are very easy to learn. I had some serious functionality written out in minutes.
Check this out also: http://groups.google.com/group/nodejs/browse_thread/thread/9d9b301479851b1f?pli=1
I played a little bit with node.js, tried out socket.io - but in the end did a big project with APE.
I think, as always, there is the question of what you want to achieve.
Only comparing the server parts: With node.js you get a machine that won't do anything on it's own, you need to write it yourself (or use libraries)
With APE, the handling of channels and connections is already built in (compiled C). Still you need to build parts of your own logic on top with JS - or use the examples.
On the client side, socket.io provides a client framework with three commands - and APE has it's APE_JSF that handles the connections (which brings more functionality than socket.io regarding channels)
Personally, I prefer APE, even though there is a lack of documentation for beginners.
However, keep in mind that APE won't deliver files/images, it's not a full Web-Server but optimized for real time push where it can handle ~10K concurrent users
I am working on a simple notification service that will be used to deliver messages to the users surfing a website. The notifications do not have to be sent in real time but it might be a better user experience if they happened more frequently than say every 5 minutes. The data being sent to and from the client is not very large and it is a straight forward database query to retrieve the data.
In reading other conversations on the topic it would appear that an AJAX push can result in higher server loads. Since I can tolerate longer server delays is it worth while to have the server push notifications or to simply poll.
It is not much harder to implement the push scenario and so I thought I would see what the opinion was here.
Thanks for your help.
EDIT:
I have looked into a simple AJAX Push and implemented a simple demo based on this article by Mike Purvis.
The client load is fairly low at around 5k for the initial version and expected to stay that way for quite some time.
Thank you everyone for your responses. I have decided to go with the polling solution but to wrap it all within a utility library so that if they want to change it later it is easier.
I'm surprised noone here has mentioned long-polling. Long polling means keeping an open connection for a longer period (say 30-60 seconds), and once it's closed, re-opening it again, and simply having the socket/connection listen for responses. This results in less connections (but longer ones), and means that responses are almost immediate (some may have to wait for a new polling connection). I'd like to add that in combination with technologies like NodeJS, this results in a very efficient, and resource-light solution, that is 100% browser compatible across all major browsers and versions, and does not require any additional tech like Comet or Flash.
I realize this is an old question, but thought it might still be useful to provide this information :)
Definitely use push its much cooler. If you just want simple notifications I would use something like StreamHub Push Server to do the heavy-lifting for you. Developing your own Ajax Push functionality is an extremely tricky and rocky road - you have to get it working in all browsers and then handle firewalls and proxies killing keep-alive connections etc... Why re-invent the wheel. Also, it has a similarly low footprint of less than 10K so it should suit if that is a priority for you.
Both have diferent requirements and address diferent scenarios.
If you need realtime updates, like in an online chat, push is a must.
But, if the refresh period is big, as it is in your case (5 minutes), then pool is the appropriate solution. Push, in this case, will require a lot of resource from both the client and the server.
Tip! try to make the page that checks the pool fast and clean, so it doesn't consumes a lot of resources in the server in each request. What I usually do is to keep a flag in memory (like in a session variable) that says if the pool is empty or not... so, I only do havy look in the pool only if it is not empty. When the pool is empty, which is most of the time, the page request runs extremely fast.
Because using a push requires an open HTTP connection to be maintained between your server and each client, I'd go for poll as well - not only is that going to consume a lot of server resources but it's also going to be significantly more tricky to implement as matt b mentioned.
My experience with polling is that if you have a frequent enough polling interval on a busy enough site your web server logs can get flooded with poll requests real quickly.
Edit (2017): I'd say your choices are now are between websockets and long polling (mentioned in another answer). Sounds like long polling might be the right choice based on the way the question mentions that the notifications don't need to be received in real time, an infrequent polling period would be pretty easy to implement and shouldn't be very taxing on your server. Websockets are cool and a great choice for many applications these days, sounds like that might be overkill in this case though.
I would implement a poll just because it sounds simpler to write, and keeping it simple is very valuable.
Not sure if you have taken a look at some of the COMET implementations out there (is that what you mean by AJAX push).
If the user is surfing the site, won't that in effect be requesting information from the server that this notification can piggy-back on?
It's impossible to say whether polling will be more expensive then pushing without knowing how many clients you'll have. I'd recommend polling because:
It sounds like you want to update data about once per minute. Unless notifications are able to arrive at a much faster rate than that, pushing would mean you're keeping an HTTP connection open but seeing very little activity on it.
Polling is built on top of existing HTTP conventions, so any server that talks to web browsers is already ready to respond to ordinary Ajax requests. A Comet– or Flash socket–based solution has different requirements; you'll need something like cometd on the server side and a client-side library that groks server-side push.
So if you needed something heavy-duty to manage a torrent of data and a crapload of clients, I'd recommend Comet. But that doesn't seem to be the case.
There's now a service http://pusherapp.com that is trying to solve this problem once and for all, in a blink. Might be worth checking out. (disclaimer: i am in no way associated with them).
I haven't tried it myself, but some say COMET works and is easier than you think. There's also a Ruby on Rails plug-in called Juggernaut that I've heard talked about highly. Again, I haven't used it, so YMMV, but my understanding is that it takes far fewer resources compared to polling. I believe (can someone confirm?) that COMET is how MacRumorsLive.com delivers live blogging of WWDC Stevenotes.