On 11/6/14, 4:04 PM, Matthew Jordan wrote:
eg -
Playback(http://myserver.com/monkeys.wav&http://myserver.com/can.wav&http://myserver.com/act.wav&http://myserver.com/like.wav&http://myserver.com/weasels.wav)
<--- On an empty HTTP Media cache, the previous app invocation would
probably sound pretty bad to the first caller going through this workflow.
:-)
Also, I think the inability to use & in a URI for playback really limits
the usefulness of this change. I totally understand why the typical URI
decode doesn't work, but perhaps a combination of a URI encoded & with an
HTML entity representation is a suitable alternative? eg - (%26amp; == & in
a URI in Playback and do that pattern replacement in the URI before any
other URI decoding/encoding operations. Ya, I know, it's a hack, but not
allowing multiple parameters in a loaded queryString URL is way too
restricting IMHO).
So I just replied to this part on Johan's e-mail - do you think we can
skip supporting an '&' in a resource? (How many media files are going
to be named tt-monkeys&weasels anyway?)
<snip>
Yes. I think that's perfectly reasonable.
Well, kind of. I think you're still envisioning using CURL behind the
scenes using the input provided in the JSON body of the PUT to /media_cache
to go and grab the resource from the remote server. If you go that way, I
think not only should we handle custom headers, but it's probably also not
unreasonable to provide a way to do basic/digest authentication for the GET
call as well. However, instead of that, I had envisioned being able to do a
PUT to /media_cache as a multipart MIME request where one part is the JSON
descriptor and the second part is the binary resource itself you're looking
to place into HTTP Media cache. The advantage of doing things this way is
that if you're running call control via some sort of API, that API will know
for certain when files/resources are ready to be played back and you don't
run the risk of the awkward blocking silence scenario that you have above.
However, when you do it this way, the URI description/parameter itself
doesn't make too much sense because it's not really where the resource came
from. I guess there's also a question as to whether or not we follow the
true REST practice with using POST for a brand new resource and PUT for
updates to existing resources.
I'd prefer that approach actually. Pushing media to the server is
preferable to having Asterisk attempt to pull it.
To do this correctly, I think we'll need a sorcery wizard that accepts
push configuration/objects. We had previously talked about this with
respect to a push configuration model for PJSIP, but this actually
takes it one step further with a push wizard for buckets. Since
buckets sits on top of sorcery, it feels like this is theoretically
possible... but I'm not sure yet how it would play out completely.
Josh may want to comment on this part.
I look forward to his commentary. :-)
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
Agreed, as commented on Johan's e-mail. E-Tags for the win!
I'll update the wiki from the conversation here shortly.
--
_____________________________________________________________________
-- 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
