Re: [rtcweb] realiable data service

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.

/Serge

On Tue, Jul 19, 2011 at 19:02, Emil Ivov <emcho@jitsi.org> 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
> >> <henry.sinnreich@gmail.com <mailto:henry.sinnreich@gmail.com>> 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
> emcho@jitsi.org                        PHONE: +33.1.77.62.43.30
> http://jitsi.org                       FAX:   +33.1.77.62.47.31
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

-- 
Serge Lachapelle | Product Manager | sergel@google.com | +46 732 01 22 32
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.