tOkeshu

Well it's called Remote Storage [1] but I guess we can't expect companies like Google, Apple, Amazon or DropBox to actually embrace that, isnt it?

[1] http://remotestorage.io/

tOkeshu

12년 전discuss

I generally find that using tuples of booleans this way is (sometimes) blurring the intent. Indeed, not only you have to keep in mind which boolean value correspond to which variable, but you also have to not forget what's the meaning of true and false here.

So what about the following?:

    match (width, margin_left, margin_right) {
        (auto, _, _) => { ... }
        (_, auto, auto) => { ... }
        (_, auto, _) => { ... }
        (_, _, auto) => { ... }
        (_, _, _) => { ... }
    }

Now that I write this, I can understand this style is trickier as the order here is critical. The "debate" between `match` and `if` reminds me of the same one that exists in Erlang, where I saw people more often use `case of` with booleans instead of `if`.

Moreover, is there any performance issue with matching auto for every tuple?

tOkeshu

12년 전discuss

Some people try to address this issue in Europe and especially in France. I strongly recommend anyone interested to take a look at the DIY ISP project [1]. There is also a map [2] showing existing initiatives and a previous thread on HN [3].

[1] https://www.diyisp.org/dokuwiki/doku.php

[2] http://db.ffdn.org/

[3] https://news.ycombinator.com/item?id=7006527

tOkeshu

13년 전discuss

> This is a solved problem.

There is strong technical obstacles but yes the problem is more or less solved in different ways.

The point of Randall Munroe here is to emphasis the gap between the fact the Internet made possible a lot of incredible things but sharing a simple file is still a hassle. And IT IS, creating an account is not what you can call a no-hassle process (I would probably say, do not forget about Term Of Services, but I understand no one read them nowadays).

tOkeshu

13년 전discuss

It is way more complicated than that. WebRTC is all great and shiny but there is strong obstacles to build correct data transfer applications on top of that:

- You still need a server to do the "signaling" part

- NAT are everywhere and will fail your p2p connections sometimes (14% of WebRTC calls according to Google, back in may) [1]

- Ultimately there is a problem with JavaScript API that does not allow you to download big files seamlessly

The signaling part can be solved in many ways but the server approach is the easiest and probably the most efficient/reliable one. For more informations I recommend checking an article on the infrastructure needed for WebRTC applications [2]

The NAT problem is solved by ICE via STUN and TURN [3]. TURN is the ultimate fallback, it is a media relay. TURN servers are bandwidth expensive and most of them require credentials in a way that does not fit WebRTC properly.

Finally, there is the browsers problem. None of them provide a proper and standard way to give you the ability to download a stream of data coming from JavaScript (although after checking the issue, sharefest may have solved this problem, but I don't know if it works properly with firefox). There the File API in Chrome but it is not supported in Firefox. There is the blob URI but you need the whole file to create this object. This mean that your application will slow down your browser in the case of a big file sharing [4]. Ideally I wanted to see the stream API be implemented but it seems it's not going to happen, so we need something else [5].

In conclusion, no, it's not as easy as you think it is. To have a proper file sharing application you will need to address ALL of these problems. Moreover, it's good to note that these problem are not specific to WebRTC applications. Indeed, most of these are problems we have with the Internet in general. WebRTC is just an API on top of existing solutions.

I hope this answer was not too negative but informative enough :)

[1] http://webrtcstats.com/first-webrtc-statistics/

[2] http://www.html5rocks.com/en/tutorials/webrtc/infrastructure...

[3] https://en.wikipedia.org/wiki/Interactive_Connectivity_Estab...

[4] https://github.com/Peer5/ShareFest/issues/8

[5] https://bugzilla.mozilla.org/show_bug.cgi?id=891286

EDIT: formating/typos

tOkeshu

13년 전discuss

Dropbox has a storage limit, requires an account and is non free software.

The usage proposed here is a "no-strings" attached approach. Ideally you want something you can trust, hence free software, and that does not store anything.

tOkeshu

13년 전discuss

It's a really geeky approach. The 949 problem concerns a lot of persons who does not even know what a server is.

tOkeshu

13년 전discuss

Do not forget that this solution is inherently mono-threaded and does not benefits from a proper concurrency model like node.js for example (which is also mono-threaded by "design" but provide non blocking IO).

So for big files with multiple downloaders, it can be sometimes not as good as you want it to be.

tOkeshu

14년 전discuss

Yes Fountain Codes are definitively something I have to look at. Improving bandwidth usage and resuming downloads are part of the next improvements with https.

For now Erlang have been an excellent fellow to deal with these things :)

tOkeshu

14년 전discuss

Theses files are examples files. You can find the same in the cowboy_examples repository[1] (Cowboy is the erlang server I use to build the application).

I should remove these files as the application do not use them.

For your information, there is no https available yet for http://fipelines.org as described in the blog post and the README. You have been warned ;)

[1] https://github.com/extend/cowboy_examples/tree/master/priv/s...

Submissions

Fixing the 949 problem with Fipes

comments