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