On Tue, 28 Dec 2010, amit paliwal wrote:

> Reply: thanks Daniel, i agree to what you are saying, but my point is
> simple, and in fact it is my question that if SSE is supported it means
> server can push events any time, right?

Not exactly.

A server can only send an event while the client is waiting for the event, and
it is only waiting for the event when it has sent a request and the connection
is still alive.

> 1) Client will initially send HTTP GET and get the response from the server
> and then it will be having persistent connection with Server.
> 2) Server can push events at any time, and the Client shoul;d be able to
> receive those events on top of HTTP as payload.

Yes.

> 3) client should be able to reply.

No. The messages are one-way from the server from what I understand. It is an
HTTP response after all.

> Client will keep the connection open and my only concern is in knowing that
> will Client be able to receive SSE on that socket connection and send
> response by using libcurl.

Yes, as SSE is plain HTTP it will work fine!

>> 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.
>
> Client will not send SSE, SSE will be received by Client and we need to
> parse it.

Exactly: "When the write callback has got enough data to construct a single
SSE message you can fire it off." And by "fire it off" I meant parse it,
consider it, take care of it or whatever you need to do with the SSE when it
has arrived at the client.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html