TL;DR: Are there examples of Angular with long-polling integration out there? (Examples, specifically Comet examples would be nice!)
Our current app uses Angular and Comet. The client sends out long-polling requests that stay open until the server has data to return. When the server returns data, the data payload might have several messages for different 'channels'.
The out-of the box Comet JS code we have uses jQuery's $.get(), $.post() methods to make the long-polling requests.
Angular is built on a light version of jQuery and adds lots of (Angular-related) magic compared to $.get()/$.post() via Angular's $http object.
I've been told the Angular's $http object and the promises it returns are not compatible with message-based front-ends, but I'm not convinced
Is it true they are incompatible?
I was thinking a different $httpProvider that is Comet aware could be written, that would provide an $http object, that based on URL could determine if it should behave in normal ajax mode or long-poll mode.
The idea here is that typically each Comet channel has a message listener and the listener has a callback it invokes passing in the message.
To me this seems like a promise in disguise. Generally, the idea would be to create a promise for each channel. When the $http object is dealing with a long-poll request, when the server responds with data it would know how to parse the payload into messages for each channel, and then resolve each channel (which is now a promise in Angular world). Resolving each channel would have the effect of calling the channels/promises then() function.
Doesn't this achieve message-based behavior with listeners and callbacks? Are these just the same things, but with different names?
I'm considering toying with the approach and possibly prototyping it. But before I do, does this even make sense?
How these promises would resolve in Angular HTML templates I'm still uncertain about.
Are there already examples of Angular with long-polling integration out there?
I couldn't find any.
"Does this even make sense?", not quite.
It would appear that what you need client-side is :
As I read the question, it seems that you may not have made a clear distinction between (1) and (2).
(1) will be a $http() request, which returns a promise.
(2) will be a bespoke function, called whenever such as request is satisfied (whenever a promise becomes fulfilled).
Thus, each polling cycle will comprise strictly one promise, but one or more broadcast events, which will be responded to by the fixed listeners.
It's like a scatter-gun, which fires a cartridge of pellets every time its trigger is pulled (and a set of willing targets that enjoy being shot).
Please note that at this level of definition, the whole thing is conceptually identical to regular short-polling, from which long-polling differs only in the timing of the requests and responses (such that the server is in apparent control).