使用Co-browsing 有几个好处。例如，教师可以使用它培训用户如何使用某个应用程序；客户服务人员可以使用它为用户处理困难任务；它还为陈述中的每个人提供一致的外观。
IT 从业人员开发的co-browsing解决方案可以有几种不同的用途，包括客户支持、培训和娱乐。使用一个自定义的聊天程序可以作为导航详细信息的一种传输机制，不需要很多工作你就可以提供你自己的一个co-browsing解决方案。
在这篇文章中，我将添加一个co-browsing解决方案到我最近开发的一个聊天应用程序中。聊天应用程序是一个基于 XML 解决方案，使用 JavaScript 实现自动化，使用 XMLHTTP 对象作为通信机制。SQL Server 2000 负责管理后台的消息。这里有我的聊天应用程序的文件。
在功能模型中，我设置了一个动作类型来实现额外的功能。（动作类型存储在一个表中。）而且还可以创建不同动作类型的消息。如果我创建一个动作类型来控制一个产生浏览器的导航，那么我就算是创建了一个co-browsing解决方案。
最困难的任务是确定你可以实现哪一组的co-browsing。使用一个非常简单的解决方案，我可以将 URL 传回、传出，并发送一个产生的浏览器窗口给那个 URL。然而，这并不是一个真正的co-browsing解决方案。
在考虑了多次之后，我发现需要创建一个代理来执行实际的 HTTP 请求以及提供响应给所有涉及到的co-browser。为了实现这一想法，浏览器就必须指向一个可以完成这个任务的代理。然后要实现的是决定如何强制一个使用代理的浏览器绕过在浏览器设置的连接设置步骤。
在 IE 中，我可以嵌入一个可以产生浏览器窗口和捕获导航事件的对象。这样对象就可以将浏览器重定位到我的代理。而且，这个解决方案不会约束我在使用 JavaScript 的时候遇到的安全限制。这样，我就可以枚举文档中的控件和表单，然后将输入的值传递给所有的co-browsing窗口，这样动作就会通过聊天消息传播到所有其它co-browsing窗口。
为了避免自动化互操作性带来混乱，我将在嵌入的对象中创建消息，所以 JavaScript 可以取到这样消息然后在一个定时事件中将它们传回到服务器。
有了代理之后，我使用 ServerXMLHTTP 对象在服务器端创建一个指向那个 URL 的请求，然后将响应存储到本地，这样本地“缓存”就会从co-browsing窗口返回所有请求。
