markdalgleish / bespoke-remote-prototype Goto Github PK

Currently we only output into the JS console if a remote connected/reconnected successfully.. It might be cool to have this as an overlay (OSX like but a bit more decent)

We should make it easy for people to configure a custom /remote/ URL.. As a first layer of "security" for the presenters

Functionality has increased quite a bit. We should re-do the little gif and also do a nice and short screencast :)

When refreshing the page or when LiveReload updates files, the browser hangs waiting for a response from the Node server. It seems to be an issue with connect-injector, but will need further investigation.

As correctly pointed out by @markdalgleish on twitter

@originell Any thoughts on how we could make connect-bespoke-remote unaware of connect-livereload? The relationship seems a bit brittle atm

It really is. It overwrites the inject/write methods to be sure to really be in there. On the one hand that's good, because it's a real guarantee.. on the other hand it makes any other middleware that might want to inject stuff look hacky.

The hack to avoid livereload injected into the remote template might actually not be necessary.. Maybe livereload is actually also nice to have while developing your own remote, though in "presentation mode" it is not necessary anymore.

To be honest I currently don't have any good idea.. The current replace method might also be pretty slow on big presentations HTMLs I guess.

For the remote it's always useful to know your internal and external IP address.

For the internal IP:

var os = require('os')

var interfaces = os.networkInterfaces();
var addresses = [];
for (k in interfaces) {
    for (k2 in interfaces[k]) {
        var address = interfaces[k][k2];
        if (address.family == 'IPv4' && !address.internal) {
            addresses.push(address.address)
        }
    }
}

console.log(addresses)

via stackoverflow

For the external, we can just query icanhazip.com. That one is also used by an Alfred workflow, so it should be reliable. If that one breaks down we might just roll our own on a free heroku instance.

Since the 'connect' and 'open' tasks are run simultaneously with 'grunt-concurrent', there's a bit of a race happening between the two tasks. If the 'open' task wins, you get two tabs with errors. Refreshing these tabs fixes it, but it's a pretty clunky experience.

Perhaps we need some way to delay the 'open' task when in remote mode?

So while I was just thinking about something for the indicator, I stumbled upon the whole timeout/heartbeat settings for socket.io.

Since bespoke-remote is used during presentations, I guess it would make sense to set a lower close timeout, heartbeat interval and heartbeat timeout so we can detect a disconnected remote fairly quickly?

What do you think about that?