Sounds like a whole lot more bellyaching. Why so serious? Dial down your zeal friend.
BitTorrent is extensible: I see you agree with that premise since you listed UDP sockets, formalized by BEP-0029. The objections you level against WebRTC DataChannels make it sound like the particular transports you mention are somehow blessed, that it's not and won't ever be bittorrent unless it's TCP or UDP (and even if it was a hard/fast requirement, one could still benefit from WebTorrent via Firefox extensions and Chrome apps).
Who cares if you're using mmap, epoll, or inotify? Are you intimate with the performance limitations of IndexedDB in all browsers? How versed are you on the performance hit taken by File API? When do these limits become problems? Why would a browser need to keep open a filehandle for every "every" in the first place? That's certainly not at all how https://github.com/js-platform/filer works, on either it's IndexedDB or it's WebSQL backend.
As for your networking dilemmas, I recommend you check out: The network discovery api (which can enumerate UPnP and DNS-SD), WebRTC's TURN/Stun for correctly choosing from available addresses, and a whole bunch of other web stuff that you obviously don't know anything about but think is explicitly the domain of Real Serious Programming With Real Applications.
Not everyone needs to be operating at the fantastical extremes you are concocting, not all use cases are gigantic seedboxes on fat pipes. It's ok to deliver capabilities that someone else might already have, and maybe not even have some quirks or possible points of poor comparison.
You're throwing a whole bunch of technical minutia at the problem you want to have. You're picking a false fight (and one that the web has plenty of good repostes you didn't know/omitted to retort with). The web might not be the best choice for using a gigabit ethernet connection (or maybe it actually does it fine in some conditions!): the act of finding these particular points to dive deep deep into as an excuse to ignore, shun, and spit upon the expansion of human technical capabilities is a close-minded injustice. It's bigotry, simpleminded technical bigotry showing off your inability to open your mind to possibilities, unwilling to open your arms to new improved things becoming available to people who want them and will benefit from their use, it's your own intransigence in the face of the ongoing adaption and mutation going on in the world. You're in for a bumpy ride if you are going to cling so tightly to your notion of what things are for and how they ought be.
BitTorrent is extensible: I see you agree with that premise since you listed UDP sockets, formalized by BEP-0029. The objections you level against WebRTC DataChannels make it sound like the particular transports you mention are somehow blessed, that it's not and won't ever be bittorrent unless it's TCP or UDP (and even if it was a hard/fast requirement, one could still benefit from WebTorrent via Firefox extensions and Chrome apps).
Who cares if you're using mmap, epoll, or inotify? Are you intimate with the performance limitations of IndexedDB in all browsers? How versed are you on the performance hit taken by File API? When do these limits become problems? Why would a browser need to keep open a filehandle for every "every" in the first place? That's certainly not at all how https://github.com/js-platform/filer works, on either it's IndexedDB or it's WebSQL backend.
As for your networking dilemmas, I recommend you check out: The network discovery api (which can enumerate UPnP and DNS-SD), WebRTC's TURN/Stun for correctly choosing from available addresses, and a whole bunch of other web stuff that you obviously don't know anything about but think is explicitly the domain of Real Serious Programming With Real Applications.
Not everyone needs to be operating at the fantastical extremes you are concocting, not all use cases are gigantic seedboxes on fat pipes. It's ok to deliver capabilities that someone else might already have, and maybe not even have some quirks or possible points of poor comparison.
You're throwing a whole bunch of technical minutia at the problem you want to have. You're picking a false fight (and one that the web has plenty of good repostes you didn't know/omitted to retort with). The web might not be the best choice for using a gigabit ethernet connection (or maybe it actually does it fine in some conditions!): the act of finding these particular points to dive deep deep into as an excuse to ignore, shun, and spit upon the expansion of human technical capabilities is a close-minded injustice. It's bigotry, simpleminded technical bigotry showing off your inability to open your mind to possibilities, unwilling to open your arms to new improved things becoming available to people who want them and will benefit from their use, it's your own intransigence in the face of the ongoing adaption and mutation going on in the world. You're in for a bumpy ride if you are going to cling so tightly to your notion of what things are for and how they ought be.