I would like to show you guys the beta of sitesupport. We launched a preview in march this year which was well received and got some great feedback.
You can read how to use the service on the website, but let me explain here how it works underneath. When a new session is started, a person requesting support is redirected to our page which proxies all of the original website. The person joining the browser session will then be served the exact same resources without hitting the target server again. In addition, the first user's browser streams all the events happening on a page via a WebSocket? connection, to be replayed on the viewing browser(s). The use of a proxy has two major benefits:
the viewers are guaranteed to get the same resources
we can modify the resources to have the properties we need
Still, there's ton of things that can (and will) go wrong. Basically, we need the state of the javascript application to be identical on both sides, which is a hard problem as there are a lot of different variables at play.
Currently the service works with simple websites. The less advanced features you have, the better chance there is to have it working on a particular website. Eventually though, we plan to offer full HTML5 support.
The backend is built with Python/Gevent/Redis/Postgres?. We also use C for processing html at "real-time" speed. Since we need to parse/modify/serialize almost every text resource, most of the Python parsers introduce unacceptable latency in browsing. Even crazy fast lxml is not good enough (performance-wise). We thus built our own single-pass parser based on a state machine.
You can read how to use the service on the website, but let me explain here how it works underneath. When a new session is started, a person requesting support is redirected to our page which proxies all of the original website. The person joining the browser session will then be served the exact same resources without hitting the target server again. In addition, the first user's browser streams all the events happening on a page via a WebSocket? connection, to be replayed on the viewing browser(s). The use of a proxy has two major benefits:
the viewers are guaranteed to get the same resources we can modify the resources to have the properties we need Still, there's ton of things that can (and will) go wrong. Basically, we need the state of the javascript application to be identical on both sides, which is a hard problem as there are a lot of different variables at play.
Currently the service works with simple websites. The less advanced features you have, the better chance there is to have it working on a particular website. Eventually though, we plan to offer full HTML5 support.
The backend is built with Python/Gevent/Redis/Postgres?. We also use C for processing html at "real-time" speed. Since we need to parse/modify/serialize almost every text resource, most of the Python parsers introduce unacceptable latency in browsing. Even crazy fast lxml is not good enough (performance-wise). We thus built our own single-pass parser based on a state machine.