Matthew Jordan wrote: <snip>
I think this is the way to do this in the long run. There's some major technical hurdles to overcome with this, however: (1) A remote file stream doesn't have the ability to do a 'parallel fetch' the way it is proposed on the wiki page. For video streams, that means Asterisk would (finally) have to understand media container formats, which is a *very* large project. (2) There are the obvious technical issues dealing with buffering, overrun of the network download, and other off nominal kinds of things. I think those are reasonably well understood, or at least can be thought through. (3) The largest concern I have is that I can't envision the API for this. Currently, Asterisk channels support two file streams - one for audio, one for video. Those streams are opaque objects managed by the file API (file.h). If this fits behind that API, then there are some serious things to work through with how that API works. If it is a separate type of stream and a different object, then we can't take advantage of the remote stream in all of the existing applications, which would be unfortunate. I think - for the purposes of this project only - I'd go with the following philosophy: Make the media cache/HTTP playback blocking for now, but put the hooks in for an asynchronous access to the retrieved bytes for future expansion. That way the larger questions above can be dealt with separately, but the information is available for what that occurs.
I hesitate to even say put the asynchronous hooks in because without scoping out how the core would look and behave chances are (speaking from experience) that what you do will be inadequate or just end up being thrown out.
<snip>
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.
It's all such a thin layer that you can do whatever you want. No matter whether it is sorcery or bucket, the implementation is only called into when the resource is requested - and ultimately the caller doesn't care where it comes from. This being said there's nothing in the sorcery core acting as a cache or place for this stuff - that's up to the wizards. As well in bucket what wizard is used is determined based on the URI scheme - and there can be only one impl for each scheme.
Cheers, -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.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
