On Wed, Nov 5, 2014 at 3:58 AM, Johan Wilfer <[email protected]> wrote: > Den 2014-11-05 08:45, BJ Weschke skrev: >> >> >> As for the timestamps for deciding whether the local cache is dirty, I >> don't think we should try to reinvent the wheel here. We should stick >> what's already well established for stuff like this and use the entity >> tag (Etag) response header stored and then use the "If-None-Match" >> request header approach. Google does a much better job of explaining it >> than I can here: >> >> https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching >> > > +1 This was my thought as well. We should stick to the HTTP standard, and > not have our own way of doing caching. In HTTP you have two models: > 1. Timestamps (header "Expires") > 2. E-tag for validation of the resource (header "If-None-Match").
Yup, E-tag is the way to go here. I'll punt on my suggestions that I have on the wiki and re-write it to note that. Thanks! > I would also like to add that we really should have a way of using & in an > url. Wouldn't this be a much more common use-case than to play in parallel? > Maybe the parallel payback can be enabled/disabled by a extra flag in the > dialplan? This way you would lose the ability to have an amp in the url if > you would like to do parallel playback but not otherwise. I think that would > be acceptable... Consider a sound resource named "stuff&things". This is technically a valid resource name, so long as the "&" is URI encoded: http://myserver.com/sounds/stuff%26things If this was a query of some sorts, then my URI my look something like this: http://myserver.com/sounds?media=yes&file=stuff%26things This is where things break down in Asterisk dialplan (keeping in mind that for ARI, you could put all of this into a JSON blob and not care.) If we allowed '&' to be URI encoded in the Playback dialplan application, this would look like: same => n,Playback(http://myserver.com/sounds?media=yes%26file=stuff%26things) And when Asterisk decoded the URI, it would turn this into: http://myserver.com/sounds?media=yes&file=stuff&things Which is very, very wrong. This has nothing to do with playing sounds in parallel, but with Asterisk's nomenclature for delineating sequential sounds to playback (that is, playlists). The '&' is already a reserved keyword for that, so we have to escape it in some fashion before passing it to the dialplan applications. Now, as BJ pointed out, we could escape things in *different* ways - but I'm concerned that doing that would make things more complicated and prone to breaking. As an API usage, it also makes it hard to know how to pass data to Asterisk - the more custom things are, the harder it is to know what to do. URI escaping is common; custom Asterisk-y escaping is ... not. All of this is a long way of saying that I'd be happy if we supported '&' in a URI, but only at the expense of *not* supporting a URI escaped '&' in a resource in that URI. > > Overall I must say that this is very simple and cool idea and a nice way to > do scalability. Thank you! :-) Well, keep in mind this is just a proposal. It's no promise that it will happen. We'll need assistance to have this feature actually show up in Asterisk 14! -- Matthew Jordan Digium, Inc. | Engineering Manager 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
