Surfly - Surf together on the web(surfly.com) |
Surfly - Surf together on the web(surfly.com) |
I guess the better approach would have been to load the website on client end and only send the DOM to your server OR the other client directly.
If you do it purely through some sort of script include, you will not be able to hook into 3rd party widgets for example and there are more things that are problematic.
Good work though!
The example you give is exactly how we use it ourselves to plan milestones and review code with remote workers. Read more here: http://www.surfly.com/blog/2013/10/31/using-surfly-for-remot...
In TogetherJS both people are basically browsing like normal, but it communicates what's going on between the people (so for example you can see the other person's mouse), and synchronizes select things like forms. With the model of Surfly and Browser Mirror, one browser is the source, and the other is viewing what that other browser does. Everything "happens" on the source browser. This is in a session like this both people are logged in as the same person and seeing exactly the same thing, while with TogetherJS each person is logged in as themselves.
Next, Surfly just works on any website - without the need to write a single line of code. For example, you can use it right now on GitHub. If you wanted to have such functionality with TogetherJS you would have to modify your website accordingly (i.e., by using a special version of the Ace editor).
I also understand its an early product, because on the spectator's screen, the HTML does not seem to be rendered properly.
With that said, (and as much as i hate to do feature requests), please allow us to speak via the mic. cheers!
http://www.deanmao.com/2012/08/28/modify-a-site-you-dont-own...
I did it the same way -- parse & rewrite js code, and have a server that stores the same cookies that your browser would. The browser js code also contains the same js rewriter so that it can handle stuff like eval(). It also had to do lots of header manipulation since there are lots of headers that have domain-name based security, like CORS for example. The one I wrote works great with js-heavy sites like gmail or facebook.
The service could work locally, with perhaps only the interactive events synced across the clients. As far as I see it, everything passes through the surfly servers, so I'd be reluctant to "surf together" on any sites that require logins.
We don't have every corner case covered yet - but we're working on it.
But the biggest difference is the use case, you would use TogetherJS to add collaboration on your site by writing a bit of code. You would Surfly to share your web session with someone else (no need to code, works on any website), use it to explain things, demonstrate your app or give remote product demo's.
Why am I allowed to login into say, Trello.com, while I am on surfly.com domain? Shouldn't my browser's cross-domain security policy prohibit this practice?
Is it all being done through a proxy? If so, is it not true that a lot of sites don't work over proxy?
[Edit] And if it is indeed proxy, doesn't that mean you can read my password(s) in clear text?
The connection to the proxy is encrypted and if the site you login also uses https, your password will never be send in clear text over the wire. Since form submissions are not actually replayed on the viewer's side, we only keep them for the time of the request and only in memory. For those companies who want to control the security fully we are working on a on a solution that can be installed on-premise.