On Mon, 27 Dec 2010, amit paliwal wrote:
Reply: please refer to http://dev.w3.org/html5/eventsource/ standard.
That is an API defined by the W3C. That API works on top of HTTP yes, but it can't change the way HTTP works.
HTTP is defined in RFC2616 - which is being updated by the IETF httpbis working group (in which I participate). libcurl speaks HTTP pretty good.
It says server-sent events can be passed on top of standard HTTP, server sent events abbreviated as SSE is a technology to push events to client any time, so it means any client having persistent HTTP connection should be able to receive SSE (which is asynchronous data) from server. Now normally HTTP is a request-response model, where the client send the request and wait for the response. for SSE we need not to first sent a request, and this is why I asked whether we can do it by libcurl or not.
I'm sorry, but that's not how I would describe things. HTTP is always request- response and adding an API on top of it doesn't change the way HTTP works. As the page you linked to also describes, SSE is still request-response and it does exactly what I previously guessed: the client makes a request and the connection is kept alive for a long time during which the server feeds the client with data according to the spec.
If some SSE comes on socket, will libcutl call my callback's for header and payload? and if yes, then after parsing will i be able to send a GET message by calling curl_easy_perform()?
libcurl offers both blocking and non-blocking interfaces and you can decide which one is best suited for your application. When the write callback has got enough data to construct a single SSE message you can fire it off.
-- / daniel.haxx.se ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
