<div dir="ltr">[Apologies for replying to the digest, seems like it's digest-only or all messages directly? Responding inline.]<br><div class="gmail_extra"><br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Oct 23, 2013 at 11:08 PM, Paul Belanger <span dir="ltr"><<a href="mailto:paul.belanger@polybeacon.com" target="_blank">paul.belanger@polybeacon.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div>On Wed, Oct 23, 2013 at 5:27 PM, Naftoli Gugenheim <<a href="mailto:naftoligug@gmail.com" target="_blank">naftoligug@gmail.com</a>> wrote:<br>


> Hello. I am very excited about Asterisk 12 and ARI.<br>
><br>
> I noticed on the wiki that while most of the API endpoints (used to talk<br>
> *to* asterisk) are true REST, using HTTP, the events endpoint would actually<br>
> use websockets, not HTTP. Many people don't realize it, but although<br>
> websockets is often associated with "server push," HTML5 introduces another<br>
> way to do server push efficiently, that works over HTTP, namely<br>
> SSE/EventSource. (See e.g.<br>
> <a href="http://www.html5rocks.com/en/tutorials/eventsource/basics/" target="_blank">http://www.html5rocks.com/en/tutorials/eventsource/basics/</a>.) Although the<br>
> basic idea is nothing new; for instance CouchDB lets you watch events<br>
> streamed over HTTP<br>
> (<a href="http://guide.couchdb.org/draft/notifications.html#continuous" target="_blank">http://guide.couchdb.org/draft/notifications.html#continuous</a>). Websockets<br>
> are a much more powerful protocol, allowing for 2-way communication inline.<br>
><br>
> In some scenarios it may require more setup for application developers to<br>
> access websockets. For instance some platforms don't have the capability<br>
> built in and require adding a third-party dependency.<br>
> I would therefore like to request that you expose an HTTP endpoint that<br>
> streams events in a connection that can be kept open, preferably using the<br>
> SSE format.<br>
><br>
> Another argument that can be made, is that REST and websockets are two<br>
> different protocols. Instead of implementing the API half in one protocol<br>
> and half in another, why not have a complete REST API, *and* a complete<br>
> websockets API? After all, websockets are 2-way, so why not let websocket<br>
> users send commands to asterisk through it as well?<br>
><br>
</div></div>Well, if I understand properly, now that the stasis bus is there,<br>
adding different interfaces shouldn't be to difficult. However, I'm<br>
not sure I'd want to see Asterisk try and implement every possible way<br>
to do this.<br></blockquote></div></div></div></blockquote><div><br></div><div>I'm not suggesting to add interfaces, I'm requesting that the interfaces you already implement should each expose the complete API. See below...</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
That said, I'm in the process of figuring out how to handle the event<br>
now too. Right now, using python-ari (tornado), I have a websocket<br>
open streaming events from ARI. I'm thinking that I'd then take said<br>
events and drop them into AMQP and moving them back to the core of my<br>
applications.  As I bring a new asterisk nodes online, I simple fire<br>
up the WS / AMPQ wrapper and go from there.<br>
<br>
I'm not too familiar with SSE, but assuming something like tornado<br>
support them, it wouldn't be too hard to add them into the python<br>
library<br></blockquote></div></div></div></blockquote><div><br></div><div>To be clear, SSE is a side detail. The main point is that HTTP is fully capable of streaming events, without requiring polling. For instance CouchDB doesn't use SSE, but it still exposes an HTTP REST endpoint that streams events. SSE is about a particular browser api, and a specific format for the events to be written in.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span><font color="#888888"><br>
--<br>
Paul Belanger | PolyBeacon, Inc.<br>
Jabber: <a href="mailto:paul.belanger@polybeacon.com" target="_blank">paul.belanger@polybeacon.com</a> | IRC: pabelanger (Freenode)<br>
Github: <a href="https://github.com/pabelanger" target="_blank">https://github.com/pabelanger</a> | Twitter: <a href="https://twitter.com/pabelanger" target="_blank">https://twitter.com/pabelanger</a><br>
<br>
_______________________________________________<br>
asterisk-app-dev mailing list<br>
<a href="mailto:asterisk-app-dev@lists.digium.com" target="_blank">asterisk-app-dev@lists.digium.com</a><br>
<a href="http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev" target="_blank">http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev</a><br>
</font></span></blockquote></div><br></div><div class="gmail_extra">Just adding my 2 cents as we talked about this on IRC the other day,</div><div class="gmail_extra"><br></div><div class="gmail_extra">Seems like adding this wouldn't be difficult (my limited knowledge of stasis etc), but I'm not sure if we should just go adding transports because we can...</div>
</div></blockquote><div><br></div><div>I'm not suggesting to add new transports. I'm suggesting that whichever transports you support, should implement the full API. Apparently you've already chosen to support both HTTP and websockets.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">
<div class="gmail_extra"><br></div><div class="gmail_extra">Server Sent events are a proposed spec and have not been formalised.</div></div></blockquote><div><br></div><div>See above, SSE is just a detail, the point is that events can be sent with HTTP REST.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br></div>
<div class="gmail_extra">I don't see an issue using Websockets, it's a nice, structured way of getting data, and we may, one day, use the two way comms available to us, if this happened, then you'd have Server Sent events, websockets and HTTP REST API</div>
</div></blockquote><div><br></div><div>SSE is not an alternative to a REST API, it's an implementation detail of an "events" REST endpoint. The main point is simply that there should be an events REST (=HTTP) endpoint. Second, it would be great if it didn't require polling (so stream chunks). Third, it would be extra icing on the cake, if those chunks would be in SSE format.</div>
<div>There's one really cool thing in SSE that I don't know whether websockets supports out of the box: If the client goes offline, when it goes back online it can tell the server the last event id it knows about, and the server can send it all the events that it missed.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">
<div class="gmail_extra"><br></div><div class="gmail_extra">Websockets have nice libs in *most* langs now, so they can be consumed very easily.</div></div></blockquote><div><br></div><div>Look, if you would have a complete websockets API I would have no complaint. :) What I don't like is that part of the API is done as REST, and the other part is done as websockets. Wouldn't it make more sense, that whatever technology or technologies you use to expose the API, exposes the complete API?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br></div>
<div class="gmail_extra">My biggest issue with SSE is that it's a draft and could completely change, and that's not good for something like Asterisk, it's fine for something that isn't released as a product people will be using in 3 years when standards have moved on. Websockets have an RFC.</div>
</div></blockquote><div><br></div><div>You don't have to claim that you're adhering to the SSE standard (see above)...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra"><br></div><div class="gmail_extra">We did talk in the IRC chat about how the docs are a little misleading, as it lists /events in the API docs when it's not really a REST endpoint; so maybe we could improve that.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">Dan</div><div class="gmail_extra"> <br></div></div></blockquote><div> </div><div>Thanks!</div><div><br></div><div><br></div><div><br></div></div></div></div>