Re: [rtcweb] realiable data service

[Stefan Håkansson LK <[e-mail]>]

On 2011-07-19 19:09, Serge Lachapelle wrote:
> There are many very established ways to transfer files from a web
> browser. Dropbox, Google Docs, yousendit, mobileme, not counting the
> media specific ways, such as Flickr, Spotify, Youtube, etc... All
> offering great APIs for uploads, ACLs, etc...
>
> Seems like re-inventing the wheel.
I tend to agree. What the data channel of rtcweb could provide is 
shorter latency - but to me that does not seem relevant for a file transfer.
>
> /Serge
>
> On Tue, Jul 19, 2011 at 19:02, Emil Ivov <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>
>
>     На 19.07.11 18:37, Randell Jesup написа:
>      > On 7/19/2011 11:58 AM, Justin Uberti wrote:
>      >> At Google, we created a TCP/ICE-UDP layering to solve this exact
>      >> problem, using a user-mode implementation of TCP. It has some rough
>      >> edges, but has worked well in practice, and the code is freely
>     available.
>      >
>      > Right; pretty much what I'd anticipate
>
>     +1 most definitely. Again, I have yet to see a massively used RTC
>     application that doesn't have file transfer. So if this is not part of
>     RTCWEB we will basically be asking developers to reimplement Pseudo TCP
>     in JavaScript.
>
>     Emil
>
>      >, and working open code is good.
>      > SCTP as mentioned is a good choice too, and there exist (it appears)
>      > SCTP-over-UDP implementations, which may ease things.  Also the
>      > TCP-over-UDP library I pointed to.
>      >
>      >> We know people will want/need a reliable messaging mechanism for p2p
>      >> data. While we can debate the details of this mechanism at length, I
>      >> suspect anything we choose will result in a better end-state than if
>      >> we require application developers to implement their own.
>      >
>      > As is obvious from my other messages, I agree wholeheartedly.
>      >
>      >> On Tue, Jul 19, 2011 at 7:16 AM, Henry Sinnreich
>      >> <[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail]
>     <mailto:[e-mail]>>> wrote:
>      >>
>      >>     +1
>      >>     Maybe it would be useful for the proponents of this and many
>     other
>      >>     “desirable” features to think from the perspective if they would
>      >>     have to pay themselves for such developments and also make the
>      >>     code freely available.
>      >>     Cullen at least will make his code available.
>      >>
>      >
>      > See above.  No one here wants to develop *another* reliable
>     protocol if
>      > we can avoid it.  I understand your reluctance.
>      >
>      > The goal is to produce something that will meet the needs and get
>     used.
>      > If we don't meet the
>      > needs of the prospective users it's either an total waste of time (if
>      > they ignore this effort and stick
>      > with Flash/plugins/etc) or we get all sorts of
>      > hack/bad/problematic/incompatible implementations
>      > by individual developers using the UDP (or RTP!) streams we open as a
>      > base transport.
>      >
>      > To your point, another way this effort could fail is by biting
>     off too
>      > much or taking too long to
>      > converge, which is a real danger.  That's one reason to leverage
>      > existing protocols.
>      >
>
>     --
>     Emil Ivov, Ph.D.                       67000 Strasbourg,
>     Project Lead                           France
>     Jitsi
>     [e-mail] <mailto:[e-mail]>
>       PHONE: [phone] <tel:%2B33.1.77.62.43.30>
>     http://jitsi.org                       FAX: [phone]
>     <tel:%2B33.1.77.62.47.31>
>
>     _______________________________________________
>     rtcweb mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
>
> --
> Serge Lachapelle | Product Manager |[e-mail]
> <mailto:[e-mail]> |[phone]
> <tel:%2B46%20732%2001%2022%2032>
> Google Sweden AB | Kungsbron 2, SE-111 22 Stockholm | Org. nr. 556656-6880
>
> Apparently, this footer is required in Europe. Apologies. This email may
> be confidential or privileged.  If you received this communication by
> mistake, please don't forward it to anyone else,please erase all copies
> and attachments, and please let me know that it went to the wrong
> person.  Thanks.