Jan Lehnardt
added a comment - 31/May/11 18:04 Nobody submitted a review of the proposed patch. We've also been busy with the 1.1.0 and 1.0.3 releases. Developer time is not infinite and this is a volunteer effort.
If you like to review the proposed patch, we'd like to hear about your results.

"Implementors should be aware that this specification is not stable. Implementors who are not taking part in the discussions are likely to find the specification changing out from under them in incompatible ways. Vendors interested in implementing this specification before it eventually reaches the Candidate Recommendation stage should join the aforementioned mailing lists and take part in the discussions."

Jan Lehnardt
added a comment - 31/May/11 18:05 In addition, the link cites:
"Implementors should be aware that this specification is not stable. Implementors who are not taking part in the discussions are likely to find the specification changing out from under them in incompatible ways. Vendors interested in implementing this specification before it eventually reaches the Candidate Recommendation stage should join the aforementioned mailing lists and take part in the discussions."
That's an even better reason for not yet committing this to trunk.

Grigory V.
added a comment - 31/May/11 18:24 That's about web browser developers. Who already did it, ignoring this stupid warning.
Have you seen the code? It's too simple to have any bugs. It's the same streaming feed with a different Content-Type, "data:" before each line and two line breaks after.

Grigory, we've got to support that implementation in the future. Implementing standards that are subject to change adds a maintenance burden. I don't consider it wise to accumulate these burdens with the limited volunteer resources we have.

Jan Lehnardt
added a comment - 31/May/11 18:47 Grigory, we've got to support that implementation in the future. Implementing standards that are subject to change adds a maintenance burden. I don't consider it wise to accumulate these burdens with the limited volunteer resources we have.

Christopher Bonhage
added a comment - 12/Sep/11 18:58 This patch is based off of the one on Github with some additional cleanup. It also now sends chunks as an io_list instead of appending into a single string.
EventSource is a great alternative to the tremendous overhead of longpoll. I would love to see this adopted; it seems like a great fit for the _changes feed.

Christopher, the patch looks clean and nicely done, thanks! Would you consider writing test cases for this in either etap or the JavaScript?

Everybody, since the EventSource is not yet (as far as I can tell) a final standard, how about naming the feed option value "experimental-evensource" or "eventsource-draft" and rename it to "eventsource" once the spec is final?

Jan Lehnardt
added a comment - 13/Sep/11 19:57 Christopher, the patch looks clean and nicely done, thanks! Would you consider writing test cases for this in either etap or the JavaScript?
Everybody, since the EventSource is not yet (as far as I can tell) a final standard, how about naming the feed option value "experimental-evensource" or "eventsource-draft" and rename it to "eventsource" once the spec is final?

Personally, I'd prefer to see the "feed" query parameter dropped entirely and have the selection of the feed switch to an Accept header-based (i.e., content negotiation-based) approached. That would allow us to respond correctly to requests for the new text/event-stream content type. A wider ranging change of this kind would of course warrant its own ticket.

At any rate, using the temporary "experimental-eventsource" thing is fine as long as we support both during the transition to the "eventsource" final option.

Benjamin Young
added a comment - 13/Sep/11 21:58 Personally, I'd prefer to see the "feed" query parameter dropped entirely and have the selection of the feed switch to an Accept header-based (i.e., content negotiation-based) approached. That would allow us to respond correctly to requests for the new text/event-stream content type. A wider ranging change of this kind would of course warrant its own ticket.
At any rate, using the temporary "experimental-eventsource" thing is fine as long as we support both during the transition to the "eventsource" final option.

No objection to adding smart accept handling on top of the feed option, but since it is cumbersome at best and impossible at worst to set accept headers (curl, browsers) I don't think feed= should be deprecated anytime soon.

I'd say that accept handling here is out of scope of this particular ticket and if that should also be added, someone (hi Benjamin should open another ticket.

Jan Lehnardt
added a comment - 13/Sep/11 22:03 No objection to adding smart accept handling on top of the feed option, but since it is cumbersome at best and impossible at worst to set accept headers (curl, browsers) I don't think feed= should be deprecated anytime soon.
I'd say that accept handling here is out of scope of this particular ticket and if that should also be added, someone (hi Benjamin should open another ticket.