Roadmap?

[NV]

Some things have happened lately. Firefox 4 beta supports WebSockets. LiveReload pops out and its server is using WebSockets. As I see it, next reasonable steps would be:

• WebSockets-based XRefresh for Firefox
• The same file monitoring server for XRefresh and LiveReload

Current response format of LiveReload is just a filename string, like main.css or index.html. I think we should send full path, like /Users/nikitavasilev/Sites/tmp/test.html. Some benefits:

1. The filename doesn't work well when few CSS/JS-files named the same. For instance, foo/main.css and bar/main.css.
2. A full path will allow as to do a "strict mode" when we edit something on file:// scheme.

darwin, how hard would be to port XRefresh to WebSockets? LiveReload developers (andreyvit and dottedmag), what do you think about the same server?

[dottedmag]

I agree the single file monitoring server is a good idea. I asked andreyvit already about passing full paths, the culprit seems to be the path<->URL matching scheme.

[andreyvit]

Agreed here too, same server would be great. Regarding the full path vs. basename only, I was passing basename because I wanted Ruby's File.basename to handle stripping the path for me. I agree I should be passing the path instead, and have JavaScript side intelligently match as many path components as it can.

[NV]

This will be enough for most cases:

function basename(path) {
  var index = path.lastIndexOf("/")
  return path.slice(index + 1)
}

[darwin]

Hi guys, nice job on LiveReload. I have had rewrite of XRefresh under websockets on my TODO list for several months now. But these days I'm trying to invest all my spare time to TotalFinder, so I cannot help here much, but I will keep an eye on you... :)

[andreyvit]

@NV Yes, unless you're using Windows. But yeah, it isn't hard.

@darwin Thanks. Me & Mikhail are working on a WebKit-only startup web app, and were very tired of not being able to use XRefresh. Besides, I passionately hate Firefox.