[hydra-dev] Hydra definition

Ken Hunt ken.hunt at digium.com
Tue Jun 8 15:41:53 CDT 2010


----- Original Message -----
> From: "Marc Blanchet" <marc.blanchet at viagenie.ca>
> To: hydra-dev at lists.digium.com
> Sent: Tuesday, June 8, 2010 12:34:57 PM
> Subject: Re: [hydra-dev] Hydra definition

> - good!, let me roll the ball!
> - this first cut is high-level with many "such as". great. (no
> criticism intended.)
> - as an engineer, I prefer down to the bottom technical
> requirements/features with some priorities or short/medium/long term
> goals.
> - to me, hydra is a very different beast if, for example (just for
> example): + it has just the SIP suite, or all the other protocol
> suites. Therefore, a clear list of protocols is needed.
> + it is or it is not a TDM node.
> + ...

I agree, and I now see how this IS a source of confusion. The primary reason we haven't written down a list of telephony protocols, media codecs, etc., is that we are striving for an open framework that could (IDEALLY) accommodate most any protocol. And there is some concern (at least in MY mind) that if we write down such a list, there may be an inclination in the broader community (post alpha release) to sit back and wait until the entire feature set has been implemented by Digium! 

But, among ourselves in particular, I think it would indeed be beneficial to capture a list that we'd like to make sure the framework - if not provides immediate support for, at least doesn't preclude from being supported! 

> 
> That (technical requirements/feature list with ordered priorities)
> would help me (maybe only me?) understand what we are trying to
> achieve.
> 

Nah - not only you! Let's build that list, and let's prioritize it as you suggest. And while we're at it, identify what we think should be in Alpha. 

> (right now, I've only saw commits related to a generic framework. (no
> criticism intended). It looks far from what would carry a phone call.
> So the commits do not help me neither to understand what we are trying
> to achieve.)
> 
> Marc.
> 




More information about the asterisk-scf-dev mailing list