W3C home > Mailing lists > Public > public-rww@w3.org > October 2012

Re: browserver

From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Wed, 10 Oct 2012 13:31:43 +0200
Message-ID: <CAKaEYhLQpXTYK6v0zy51uxeUh7g1oOuQ4dSL2KOYnamvYLgL_Q@mail.gmail.com>
To: public-rww <public-rww@w3.org>
On 10 August 2012 19:03, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

> http://browserver.org/
> browserver(Hey all! I'm currently getting Hacker News'ed, so if this
> doesn't work for you the first time, please refresh and try again.)
> Hello! I've got some good news for you: your web browser has just been
> upgraded to a web *server*. It's responding to HTTP requests on the
> Internet as you read this.
> True story. You can try it yourself here:
> [ see your own link ]
> Here's what just happened:
>    1. You used curl to request a resource from [ see your own link ]
>    2. A browserver server <https://github.com/jed/browserver-node>received your request, and figured out that you wanted to talk to client
>    *q6zh45q6k6kfn7b9*, which is actually your browser.
>    3. The server then used an already-established websocket-like
>    connection (thanks to engine.io<https://github.com/learnboost/engine.io>)
>    to forward the request.
>    4. The browserver client <https://github.com/jed/browserver-client> in
>    this page responded, getting any necessary input from the browser (or from
>    you). The server then forwarded this response back to you.
> In other words, the open-source browserver server and client worked
> together to give your browser a real address on the Internet.
> So?
> Well, this means that you don't need to roll your own custom code to
> connect the various pieces of your web architecture to your end clients.
> Instead, you can move the complexity of your app to the edges by making
> your end clients first-class HTTP servers, and then use your existing
> HTTP-related infrastructure to communicate with them.
> For example, you could:
>    - Subscribe them directly to any webhook-capable API, such as Amazon
>    SNS.
>    - Send notifications to other decoupled web services whenever a client
>    connects/disconnects.
>    - Simplify development by using the same familiar node.js HTTP API on
>    both the client and server.
> To learn more about how browserver works, head on over to GitHub and check
> out the browserver server <https://github.com/jed/browserver-node> and browserver
> client <https://github.com/jed/browserver-client>.

Some interesting new features in chrome may allow the browser to act more
like a server.

socket.create("tcp", {}, function(_socketInfo) {
      socketInfo = _socketInfo;
      socket.listen(socketInfo.socketId, "", 8080, 20,
function(result) {
        console.log("LISTENING:", result);
        socket.accept(socketInfo.socketId, onAccept);


With such functionality, it is maybe possible to imagine a read write web
that operates from browser to browser, rather than going through a third

> browserver was brought to you by Jed Schmidt <https://github.com/jed>.
Received on Wednesday, 10 October 2012 11:32:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:40:02 UTC