Re: What is missing for building "real" services?

On 6 Jan 2014, at 10:01, Harald Alvestrand <harald@alvestrand.no> wrote:

> On 01/06/2014 10:55 AM, Tim Panton new wrote:
>> 
>> On 6 Jan 2014, at 09:45, Harald Alvestrand <harald@alvestrand.no> wrote:
>> 
>>> On quite a few of these, coming up with specific proposals that explain:
>>> 
>>> - Why it's needed
>>> - How it could be done
>>> 
>>> would greatly increase the chances of something happening.
>>> It's very nice to ask that "someone do something"; it's much better to actually do it.
>>> 
>>> On 01/05/2014 09:59 PM, piranna@gmail.com wrote:
>>>> I have reminded myself another issues regarding specially to DataChannels:
>>>> 
>>>> * It is too much cumbersome to create a DataChannel-only connection and there are too much concepts related to it: SDP, offer, answer, PeerConnection objects, signaling channel (common sense says, if you already has a channel to comunicate between both peers, why you would create another one)... Too much complicated and anti-intuitive.
>>>> 
>>> 
>>> On this aspect, however, I think the answer is "live with it". It's just the way the design is.
>> 
>> Or perhaps 'live with it 'till 2.0' - I can't imagine the SDP mess will survive a major revision of the spec - it is just too clumsy.
> 
> I'm looking forward to the proposals being worked out in the ORCA group maturing to the point where it's possible to prove that they can be used to communicate with 1.0 implementations (or even emulate their API).

That's un-provable. The SDP subset offered by 1.0 is (and will remain) sufficiently vague that it will never be possible to be sure that 
you've handled all the possible variants. That means that ORCA can at best demonstrate interop with current 1.0 implementations. 
If you are expecting rigour from a system involving SDP you are setting them up to fail. 

> 
> The part that I think will survive "forever" is, however, the need to have a signalling path in order to start communicating. That's something I don't expect to see workarounds for.

True. But it isn't clear to me that O/A over http is the only possible mechanism for that signalling path.

>