| 经过三年时间的秘密开发，Ray Ozzie,这位Lotus Notes的创造着终于给我们带来了一个全新的功能强大的点对点协作平台----Groove。主编Steve Gillmor就Groove里的XML对象仓库和通讯技术等问题，采访了 Ray Ozzie。 Ozzie: In the last few years at Lotus and IBM, I spent more time with customers than in previous years, and I noticed specific things happening organizationally within a lot of the companies that I hadn't seen in the early days of Notes in the early '90s. More authority is being transferred to the edges of organizations. Those companies are a lot more responsive to their customers and to things going on in their external environment.
Ozzie: 我待在Lotus和IBM公司的最后几年时间里，比起前些年来说在客户的身上花费了更多的时间。并且，我发现有一些事情会在很多公司里重复的发生，这是我在九十年代初，Notes还处在早期的时候所没有注意到的。更多的权威人士被派到公司的外围部门。这些公司更加关注他们的客户和公司的外部环境。
It also means that those people self-organize a lot more into teams to solve problems or to take advantage of opportunities. These people communicate with one another largely [by] telephone, fax, or e-mail. Systems that we have built, whether based on Web or Notes technologies, are centrally planned, centrally deployed, managed, and administered, and are really good in orchestrating large-scale business processes. But they're not as pliable in terms of the spontaneous response that one needs when making decisions. At the same time, I [was] looking at my son at home playing "Quake" with his friends and, to me, this is a really good use of technology. It's using every bit of computes and display-driver power in the computer to play Capture the Flag—a domain-specific collaboration function. But people in organizations were not using [that kind of] technology to help with collaboration.
迹象表明，人们更加自觉的组成小组来解决问题或是利用机会。这些人相互之间通过电话、传真或是e-mail来进行联系。而我们所建立的系统，不管是基于Web的还是基于Notes，都是中央计划、中央布置和管理的。这在处理大规模的商业业务的时候，无疑是有很大好处的。但是对于个人做决定来说，这样的方式就实在太不灵活了。这时候，我看到我的儿子在家里与朋友一起玩”Quake”。在我看来，这个游戏太会利用技术了。它利用了计算机里所有的，包括显卡的运算能力来玩“夺旗模式”----一种特定领域内的协作。但是在工作中，人们并没有使用这种技术来帮助协作。 When we started Groove, essentially the "head space" that I was in was, "How can we use technology to augment human interaction at the edge of the organization to make it possible for them to be more effective, to better reduce time to decision, and increase responsiveness by building a new collaboration framework specifically oriented toward them?" One of the things that I learned in the whole Notes experience was that the value of computer-augmented interaction tools increases at some power based on how domain-specific the tool is.
当我开始着手开发Groove时，头脑里就想着，“我如何能够利用技术来开发一个协作平台，并针对其设计的，….,提高在组织边沿的人的交互能力，使其能更有效、更快的做出决定，有更快的反应速度，…………. File-sharing tools have been around for ages. Napster hit the mark because it's a domain-specific sharing tool. It's about sharing music, something people want to do. Within organizations, a document-management tool might be useful—a pharmaceutical document-management system might be really useful to someone in the pharmaceutical industry.
文件共享工具的出现已经是很多年前的事情了。Napster之所以火爆，是因为它是针对特定领域的共享工具，那就是共享音乐，而这正是人们想做的。在一个组织团体里，文档管理工具应该是有用的，特别是医药文档管理系统对于医药行业里的人来说，那就更重要了。
Peer to Peer
Ozzie: The platform we're building serves individuals at the edge of the organization as opposed to systems at the center. The tools that people are using successfully at the edge of the organizations—e-mail and telephone—are self-empowering tools. People don't have to ask somebody to make a phone call; they just dial the number. People don't have to ask somebody to set up an e-mail connection between them; they just send e-mail. From their perspective, it's a peer system. If we wanted to enable people out at the edge of the organization with some new type of communications functionality, it had to be a self-empowering, spontaneous type of environment. We don't view IT as the enemy or anything like that, but they couldn't be in a responsive environment—you want to empower people to get going without asking IT . . .
Ozzie: 我们的平台是针对对外人员而设计的，而不是内部系统。对外人员经常使用的工具如e-mail和电话，都是自授权工具。人们不需要告诉某人说，我要打个电话。他们只要拨入号码就可以了。人们也不需要双方事先建立一条e-mail连接，才能发送。他们只要点发送按钮就可以了。从他们的角度来说，这是一个点对点的系统。所以，如果我们要让对外人员多一种新的通讯方式的话，这种方式也必须是自授权的，很自然的。我们并不是视IT为什么可怕的敌人，只是不自然。我们必须让人们意识不到IT的存在。
Gillmor: Similar to the QuickPlace model?
Gillmor: 类似于QuickPlace模型？
Ozzie: That's right. But even QuickPlace relies on the fact that IT or some Web site has set up the QuickPlace servers and that that they're managed in some way. We decided to take a completely peer model where you don't have to rely on a central site, or Groove Networks, Inc., or an Internet connection. You could function really well if you were connected, but you could also keep working while you're disconnected—because that's the way people tend to work. And particularly people at the edge of the organizations operate in a highly mobile environment.
Qzzie: 是的。但是即使是QuickPlace也建立了服务器，并接受特定的管理。我们决定使用完全的点对点模型，你不需要依赖于任何的中央站点，或是Groove Networks，甚至 Internet连接。在线上的时候，你可以很好的工作。就是离线了，你照样可以继续工作----因为这正是人们所倾向的工作方式。特别是对于那些对外人员来说，他们的工作地点是不固定的。 A lot of the people in the peer space are thinking of "peer" either from a very specific vertical app sense, like Napster, or an aggregation of resources perspective—taking the world's computation or distributed-storage resources and aggregating them in some way. We're the inverse of that, meaning the design center of our product is to get groups of people together who need to get a job done very quickly, do the job, and go our separate ways. It's more the group focus as opposed to the public-network focus. And because of that, a lot of the things that we try to address—security for small groups of people so that the public doesn't have access, etc.—are problems that are unique and so is the way we're addressing them. If you have to put us in a box, our optimal scenario is that we're viewed as a killer platform for peer computing, as opposed to a killer specific app, like Napster is. The killer app for our platform is your app within a specific domain. Our job is to enable other people to build what they want within a domain very, very, very easily and quickly.
许多在点对点领域里的人对"点对点"的理解是这样的：一，就是像Napster那样的垂直结构。二，世界上所有的计算机资源和分布式存贮系统以某种方式的组合。正好相反，我们产品的设计思想是人们集合起来，以更快的完成工作。系统更加强调的是小组，而不是公共网络。于是，我们需要解决的问题就是如何保护小组里成员的利益，而不让其他人访问。我们的产品将是点对点计算领域里的一个强大势力，但不会对特定领域的系统如Naspter造成威胁，而对我们的产品有威胁的恰恰就是面向特定领域的系统。我们的目标就是让人们针对自己的领域来定制这个系统。
| |
|
| Figure 1. Groovy Architecture. Click here. |
Groove
Ozzie: What I've got here is two computers—not on the Internet—with one little LAN between them. Groove is not running; it's as though two people have downloaded the product from the Net and just typed their name in. They are not given certificates or IDs or anything like that by some central administrator—Groove Networks, Inc., doesn't assign them some identity. When they run the product the first time, they fill out a very simple form at the beginning and that is it.
Ozzie:现在假设我们有两台计算机，它们并没有连到Internet上，仅仅连在局域网里。这时候，Groove还没有开始运行。两个用户都下载了Groove，然后填写他们的名字。注意，他们并没有像许多有中心服务器的系统那样，得到任何的证书或是ID号，Groove Networks并没有给他们分配什么标识符。当他们第一次运行Groove的时候，他们仅仅需要填写一个非常简单的表单，就这么简单。 This is the inverse of a Web-services play. With Groove, the app lives on all the clients and the network is used as a pipe between the clients. This is not a browser-based app. We use browser technologies a lot, but the browser has a paradigm that's very locked in right now. The browser is somewhere you go to look at information and do some simple form-based interaction with Web sites—but the paradigm is principally one of pulling information from Web sites.
与Web服务所做的正好相反 ，通过Groove,应用程序分布在所有的客户机上，网络仅仅被当作客户之间联系的管道。这不是一个基于浏览器的应用程序。虽然我们大量的应用了浏览器的技术，但是现在浏览器的模式还是相当封闭的。浏览器只是被用来浏览信息，或是到web站点上做一些简单的表单填写。浏览器的本质还是从Web站点上下载信息。 An e-mail paradigm is very two-way; you've got this one-to-one relationship between you and the people whom you're dealing with. In Groove, the paradigm is that you're sharing things with sets of people; you're interacting with other people in "shared spaces." The client is called a "transceiver"—the word derives from Walkie-Talkies and similar two-way devices. [Editor's note: see Figure 1.]
e-mail的工作模式是双向的；你和对方是一对一的关系。而在Groove里，则是你与一群人在共享东西。你和其他人在“共享空间(shared spaces)”里进行交互。这里，客户被称为“收发器”，借用了无线电话的概念。 We borrow certain things from the browser to make it easier for people to work with. Where the main pane in a browser changes as you go from Web site to Web site, in Groove this changes when you go from shared space to shared space. The types of shared spaces in Groove change depending on the type of interaction you're having.
我们借鉴了浏览器的一些东西，以使Groove更简单易用。在浏览器里，主窗口会随着你浏览的网站的不同而跟着变化。而在Groove里，则是随着你所在的共享空间而变化的。共享空间的类型也会随着你发出的命令类型发生变化。 When you create a shared space, it puts you into conversation space by default. The types of tools vary with the type of shared space. The conversation type has a note pad, a Web browser, and places to put shared files and sketches. [Editor's note: see Figure 2.] Tabs indicate the various tools that are in that shared space. The left pane shows the people that are in this shared space with you; you can have many different shared spaces with different disjointed sets of people that you're working with.
当你创建了一个共享空间后，就会被缺省放入会话空间(conversation space)。各个共享空间里的工具也都各不相同。会话类型的空间里有记事本、浏览器、共享文件区和自由画板。下排的标签表示该共享空间的所有工具，而右边的面板则表示与你同在这个共享空间里的人。你可以与很多互不相干的人共享不同的共享空间。 To invite someone else into this shared space, the vast majority of people will use e-mail; we all have e-mail and it's the ubiquitous rendezvous mechanism. You package invitations in a little XML file that you attach to an e-mail message. This just says, "Hey, you've been invited to a shared space. If you don't have Groove, here's where you can go get it." Or you can use a standard Instant Messaging protocol to send an invitation. You can also record a voice greeting, "Hey, let's get together and sketch."
你可以邀请别人进入你创建的共享空间。大多数情况下，你可以使用e-mail，我们每个人都有一个独一无二的e-mail地址。你把邀请信息封装到一个很小的XML文件里，然后当作附件放入e-mail里。e-mail里写着“嘿，有人邀请你加入一个共享空间。如果你没有安装Groove,请点击这里。”或者你也可以用标准的即时消息协议，发送邀请。甚至，你可以录制一段声音“嘿，让我们一起开始吧”。
| |
|
| Figure 2. Sharing Ideas. Click here. |
Once the invitation is accepted, Groove sends the shared space over—a combination of XML metadata describing what tools are in the space and the actual data that would be in the shared space at that point in time. Remember, this is in a peer-to-peer fashion; there isn't a server involved. Both people are in this conversation space. We can be in different tools—one in Note Pad and the other in Sketch. If we both select to navigate together, then the tool that I am working in will be the tool that you're working in.
一旦邀请被接受，Groove就会马上把当前共享空间的信息包装成一个XML数据元，然后发送出去。这个数据元，描述了当前共享空间的工具，和当时的真实数据。记住，这是点对点的模式，没有任何的服务器介入。现在，双方都已经进入了这个共享空间。我们可以分别使用不同的工具。如果双方都选择了共同浏览，那么我们所使用的工具就将是同步(一样)的。 Gillmor: And vice-versa.
Ozzie: Exactly. There are many common things that you can do in all shared spaces. You can chat, sketch, and talk to each other. We default to the push-to-talk paradigm—which works very well in the variable latency of the Internet environment—or go into conference mode. These are just a few of many tools that we provide, and solution developers will build more as time goes on.
Ozzie: 正确。有一些功能在所有的共享空间里都是可用的，比如聊天、画板和语音交谈等等。我们缺省是用push-to-talk 模式，这在有不同延时的Internet环境里是非常有效的。当然，你也可以进入会议模式。这些仅仅是我们所提供的工具里的一小部分，随着时间的推移，针对不同需要的工具将会越来越多。 Gillmor: You write them to Groove's API?
Gillmor: 你把这些都写到Groove的 API 里了？
Ozzie: That's right. There are several levels of development. The simplest is a page of XML where you describe what components are in a tool. For example, in the sketch tool, there's a component for each of the elements—the sketch, the text, the buttons. You declare where the components come from, then write a little JavaScript to weave the events coming from one component sending into another. One script says "When I press this button, tell this component to instantiate a new sketch and these little navigators between them."
Ozzie: 是的。我们有不同的开发层次。最简单的就是描述一个工具所包含的组件(component)的XML文件。比如画板工具，就有画布、文字和按钮等元素，对应每一个元素有一个组件。你要说明，这个组件是从哪里来的，接着用JavaScript写一段简单的代码把一个组件发出的消息送到另个组件上面。比如一段代码是这样的“当我按下这个按钮时，创建一个新的画板”。 To the extent that you can build an app out of the rich set of components that we provide, you don't have to write anything beyond that JavaScript and that little XML page. If you want to build or use other people's custom controls, you can go deeper in the APIs and write a COM component.
由于我们提供了大量的组件，所以你仅仅需要用JavaScript,并写一些XML文件，就可以创建一个应用了。如果你想自己创建或是使用他人的组件，你就必须深入了解API，写 COM组件了。 Real- or Reel-Time
Ozzie: One thing that you'll notice that's distinctly different between Groove and NetMeeting is the fact that there is no concept of control. You both have control. All the people who are involved have control concurrently, and even though this looks like a real-time product, it's not strictly real-time. For example, let's say I go work off-line for a moment. I'll disconnect from the network, the equivalent of popping the NIC adapter in a Windows-friendly way. Now I can start to work here, and the other guy can start to work over there.
Ozzie: 你可以看到，Groove和NetMeeting之间最大的差别是，在Groove中没有控制的概念，而是双方都在控制。因为所有涉及的人员都可以同时进行控制，这使它看起来像一个实时的系统，事实上它并不是严格意义上的实时。打个比方，现在我想离线工作一会儿。于是我就从网络上断开，只要在Windows里把网卡(NIC)给禁用了，就可以了。于是，我可以在这里工作，而别人可以在他们那里工作，一点影响都没有。
Gillmor: Is he aware that you've done that?
Gillmor: 那别人知不知道你已经离线了？
Ozzie: Well, they're off-line with respect to each other right now, so they're not aware of anything. I can close my machine down, go home, and get on an airplane. When I come back, I can open the transceiver and go back to that particular shared space. Sure enough, we're still out of sync. When they discover that they're back on line, now the space is back in sync again.
Ozzie: 事实上，一个人离线并马上影响其他人，所以他们并不知道你已经离线了。我甚至可以关闭计算机、回家或是搭飞机去。当我再次回来后，我可以把接收器(transceiver)打开，重新连到网上，加入刚才那个共享空间。可以肯定，我们之间现在是不同步的，数据是有差别的。但是当系统发现我又回到线上后，这个空间就开始自动同步起来。 Fundamentally, this is an asynchronous product. It's got a very robust XML-object store underneath it that represents the persistent state of a given tool and set of tools—a given shared space. It uses this little XML element fragment-routing protocol on the wire to move things back and forth between the parties. Everything that goes on the wire between these points, and everything that goes to disk is WBXML [Wireless Binary XML] compressed and encrypted. If you look at what's going over the wire—including the voice—you can't see what's going on. If you lose your laptop, you can't see what's in the store; it's a fairly robust system that's designed for building business apps. At the platform level, we didn't want to constrain it to a certain model. We wanted it to work for both real-time apps and persistent, longer-term apps.
基本上来说，这是一个以异步模式工作的产品。对于给定的共享空间，都会有一个强大的XML存贮对象，记录了所有的工具和工具里的所有数据信息。节点之间通过XML元素路由协议，传送这些数据。节点之间传送的数据和存贮在硬盘上的数据都是经过压缩和加密的WBXML(无线二机制XML)。所以，如果你想看看网络上正在传送的数据，包括声音，你根本就看不出什么东西。如果你不慎把手提电脑给丢失了，别人也看不懂里面存贮的数据。这是一个专门为创建商业应用程序而设计的十分强壮的系统。在系统平台的层次上，我们不想限定为某种模式。我们希望系统既能以实时模式，也能以持续系统模式工作。 Gillmor: If you've got multiple users, is there an election in terms of the decision about moving from one tab or tool to another?
Gillmor: 如果有很多的用户，是否需要一个投票决定是否应该从一个工具转换到另一个工具？
Ozzie: It's an individual decision whether you're part of the "Navigate Together" group. You can disconnect from that and navigate separately.
Ozzie: 是否要加入"共同浏览"小组，完全是你个人的决定。你完全可以退出这样的小组，而自己进行浏览。
| |
|
| Figure 3. Unlimited Tools. Click here. |
Gillmor: If you've got five people and any one of them decides to go to a different place, then everybody goes to a different place?
Gillmor: 如果现在有五个人，分别想到五个不同的地方，是不是每个人都去了不同的地方？
Ozzie: If you're all in "Navigate Together" mode, that's the way it is. Everything I'm going to show you is kind of a free-for-all. There are roles, capabilities, and access controls that enable you to build apps that drive things in a more structured fashion. But we didn't want to burden the actual UI with lots of those features, so they are generally at the tool level. You might use a PowerPoint tool to do a presentation environment—the first person that presses the button takes control and everybody else goes into a "watching" mode. That's a function of the PowerPoint presentation tool, as opposed to the platform itself.
Ozzie: 如果他们都处在"共同浏览"的模式下，是这样的。事实上，这完全是自由竞争。虽然你可以建立一个拥有完善的用户权限管理的系统，这样更加符合结构化的风格。但是，我们不想在用户接口上添加这些功能，而把它们放到工具模块的层次。比如，用PowerPoint工具来做一个演示。你想让第一个按下按钮的人拥有控制权，而其他人只能观看。这个功能，完全应该由PowerPoint自己来完成，而不是系统平台。 Gillmor: And the XML metadata is how you describe it?
Gillmor: XML数据元？你是这么叫的吗？
Ozzie: Absolutely. And remember, one of the fundamental reasons why we're building the product is so that people are empowered at the edge without the app designer controlling what's in that app. Users themselves can add tools to their heart's content to the shared space. The last tab is always "Add Tool" if you're privileged to add tools. We provide a large set, and you can go to the Web site and download more. [Editor's note: see Figure 3.]
Ozzie: 当然。请记住，我们创建这个产品的主要目的就是让人们自由的在这个产品的基础上添加功能，而不用了解系统是如何工作的。用户自己就可以往自己的共享空间里添加工具。如果你有相应权限的话，工具标签的最后一项就是“添加工具”。我们提供了很多工具，你可以到网站上去下载。 You're downloading the metadata description of the tools, which declares how the app gets put together. The machine then pulls the components down from the appropriate places on the Web, installs them, and from that moment on you can instantiate them over and over and over without reinstalling.
你首先下载的是工具的描述信息，该信息描述了该工具是如何组成的。接着，系统自动从相应的网站上下载所有需要的组件，并进行安装。安装完成后，就可以反复使用，而不需要每次都安装了。 Gillmor: When you say "the Web," can the host be a corporate server?
Gillmor: 你所说的“网站”可以是一个公司服务器吗？
Ozzie: Yes. The component manager uses standard ftp or http as the file-transfer mechanism—and we integrate with our own Web services via SOAP. Developers build these tools. They package them up in the Web site for downloading, and then they just get dynamically assembled.
Ozzie: 可以。组件管理使用标准的ftp和http协议作为文件传输机制，通过SOAP与我们自己的Web服务集成。开发者把做好的工具打包放在网站上供自由下载，他们会动态的组合的。 Gillmor: How does it stick on the client? ActiveX?
Gillmor: 在客户端，它们是如何结合在一起的？ActiveX?
Ozzie: Yes, this whole thing is a big COM-component framework. We've ported to Linux, but what we use of COM is the local COM component binding. We don't use DCOM or cross-process marshalling . . .
Ozzie: 是的，整个系统就是一个很大的COM组件框架。我们已经移植到了Linux下。但是，我们所使用的COM是本地COM组件。我们没有使用DCOM，也没有使用跨线程的列集。 Gillmor: You're using SOAP instead?
Gillmor: 你们使用SOAP来代替？
Ozzie: Yes, that's right.
Ozzie: 正是。
Gillmor: What tools do you get with the free download version of the client?
Gillmor: 自由下载的客户端里都有些什么工具？
Ozzie: There is a news group discussion. You can create a new topic, save it, and there it is—it shows up in each shared space. There's a calendar for a project space or a family get-together. It's not intended to be a replacement for your Outlook calendar; it includes dates that pertain to the things that you're doing in that shared space with other people. There's a shared Web-browser component if you want to surf different places collaboratively.
Ozzie: 有一个新闻讨论组。你可以创建一个主题，保存，它就会在所有的共享空间里出现了。在项目空间和家庭组里，有一个日程安排表。它不是用来代替Outlook里的日程表的，而是你在共享空间里与人合作的时间表。还有一个共享的Web浏览组件，如果你想与对方共同浏览网页的话。 Gillmor: Is this the IE control?
Gillmor: 是一个IE控件吗？
Ozzie: Yes. Probably the tool that's going to be used the most, for better or for worse, is a simple explorer control that contains files. You can create sub-directories and drop documents and pictures in, edit and save them, and look at them in the group. It's a simple virtual shared file system.
Ozzie: 是的，而且可能会是你用得最多的组件。 它包括一个简单的explorer控件，和相应的文件。你可以创建子目录，把文档和图片拖拽进去，编辑和保存，让小组成员都看到它。这是一个简单的虚拟共享文件系统。 Gillmor: Using WebDAV?
Gillmor: 使用到WebDAV了吗？
Ozzie: No, remember, this is peer-to-peer-to-peer. Everything is happening in parallel in this architecture amongst all the clients. There's no central server.
Ozzie: 没有。请记住，这是一个点对点的系统，所有的事情都是并行发生的，没有一个中央服务器。
P2P2P
Ozzie: Our goal as a platform designer is to make the programming paradigm as easy as possible for the user, yet give them the most possible power. For example, if you were trying to write that discussion application in a client-server fashion, it's fairly easy. You send your document to the server and other people pull it from the server—it's a fairly straightforward thing. But if you have n clients and you're trying to do it without a server—with some on-line and some off-line—getting the document to those people is challenging. No one client is hosting that discussion; they're all running . . .
Ozzie: 这个平台设计的目标就是让程序的编写变得尽可能的简单，尽可能的功能强大。比如，如果你要以客户/服务器的模式写一个论坛程序，那是很简单的。你只需要把你的贴子发往服务器，然后其他人把它从服务器上拖下来，就这么简单。但是如果在没有服务器的情况下，客户有在线的，也有不在线的，你要如何把帖子发给他们？没有客户主持这个论坛，他们都在运行....... Gillmor: They're all servers.
Gillmor: 它们都是服务器。
Ozzie: They're all servers, and they're all clients. The challenge is how to get your work to all the clients. How do you do it in either real-time or store and forward fashion? How do you do it securely? How do you resolve conflicts?
Ozzie: 是的他们都是服务器，也都是客户。问题的关键就在于你如何让它对所有的客户都工作起来，如何让它在实时模式或存贮/转发的模式下工作？如何保证安全性？如何防止冲突。 Gillmor: Basic replication issues . . .
Gillmor: 基本的数据重复问题......
Ozzie: Exactly. We build on the old model-view-controller architecture. [Editor's note: see Figure 4.] UI controls are view components. We don't have a whole lot of constraints—this is a multiplatform architecture—but view components are tied to the platform. In this case, they're Windows-specific. You can party as much as you want at the Windows API—that's by design. We want you to build apps that are very tied to the environment so that you have a good, rich interface. That's in contrast to products that I've built in the past where you have the same interface on all platforms.
Ozzie: 是的。系统是建立在古老的模型-视图-控制(model-view-controll) 体系上的。(见图四)UI 控制就是视图组件。我们没有什么太多的限制，这是一个跨平台的体系，但是视图组件是与平台相关的。在这种情况下，它们是基于windows的。你可以随意使用Window API，我们就是这么设计的。我们希望你建立的程序与系统环境紧密联系在一起，以有一个漂亮而丰富的界面。这与我们以前设计的产品是不同的，那些产品不管在什么系统上都是同样的界面。
| |
|
| Figure 4. The Heart of Groove. Click here. |
Gillmor: Sort of.
Gillmor: 好像是有点。
Ozzie: Well, close.
Ozzie: 得了，别说了。 Gillmor: Let me just tease you a little bit.
Gillmor: 我只是想让你放松一下。
Ozzie: We tried to . . . it [Notes] was uniformly bad on all platforms.
Ozzie: 我们已经尝试......它(指Notes)在所有平台上的统一性很差。 Gillmor: There you go.
[laughter]
Gillmor: 好吧，继续吧。
[笑]
Ozzie: Well, I'm trying to correct the error of my ways. We learned a lot about this when we integrated with ccMail: They had a completely different philosophy—just re-implement it [the interface] for the new platform because, that way, Mac people will be very happy. We fought it tooth and nail, but it was the right solution for that type of app because then people felt like they had a native app.
Ozzie: 我正在努力解决这些问题。这些问题是在与ccMail集成的时候发现的。这个程序完全是以另外一种方式来实现的，为这个特定系统平台而设计的，因为这样做可以让Mac的用户很高兴。我们拼命想解决这个问题，最后发现就应该用这种方法来实现这样类型的程序，它让人们感觉到亲切。 We have a very clean dividing line in our porting architecture [for what] must be multi-platform. The data models must be the same; they have no UI code. Those components have to be portable cross-platform; otherwise, we can't get the data from one to the other. But how that data gets rendered is completely platform-specific. There are many different data models: the file-based data model, a directory-related model in the tic-tac-toe game, more of a document model in the pictures tool. The Web browser is very link-oriented; a calendar is event-oriented; a sketchpad is stroke-oriented.
在我们的平台中，那些可以移植的部分是有明确界线的，必须是支持多平台的。数据模型必须是可移植的，它们没有包含关于界面的代码。这些组件必须是可跨平台移植的，否则我们就不能把数据从一个地方搬到另一个地方。至于这是数据将如何显示出来就完全是与平台相关的了。数据模型很多种：有基于文件的数据的，基于tic-tac-toe游戏是基于目录的、图片工具是基于文档的，Web浏览器是基于链接的；日程表是是基于事件的；书写板是基于击键动作的。 That's a big difference from the Web and from Notes. They both have a document data model, and that's very constraining. It's great for a lot of apps, particularly ones that are form-based, but when you want to do something like a white board, how do you package that in a document data model? Do you keep sending documents back and forth, or do you just send the fragment that is the command?
这就是与Web和Notes的最大区别。后两者都使用了文档数据模型，这是有很大限制的。虽然对很多的程序来说，这种模型有方便，比如基于表单的程序。但是如果你想把该模型应用于像白板这样的程序中，就比较困难了。你不可能把文档传来传去的吧，或只是传送命令？ Finally, in our context, the controller is the glue between what's going on at the UI and what needs to be packaged for the data model. Take the sketchpad: there might be some Windows-specific code that gets the mouse-down and does the necessary input and output. The controller packages that stuff up into a little XML command description and submits it to the data model, which makes the appropriate modification in the store and then modifies the view. This is what we package as a tool, so each one of these tabs is a package of view-controller-model components.
在我们的实现里，视图与数据模型之间是通过控制来联系的。以书写板为例吧。你可能用了一些windows 代码获得鼠标击键消息，或是做一些输入输出工作。控制模块把这些操作转换成很小的XML命令描述，并传给数据模块。数据模块于是对存贮对象做了相应修改，并通知视图模块更新显示。所以一个工具就是一个数据包，标签栏上的每一个工具都是一个“视图-控制-数据模型”组件。 Then, a piece of our architecture called a command processor intercepts actions going from the JavaScript to the data model; that's how we get these items to all the other people in a peer fashion. This is unlike SOAP where you do a request and you get an HTTP reply—that's not the base paradigm of this system. We have what we call a virtual message queue. You make a command, you send it. You don't wait for a response—it's all asynchronous. That's why it works in this disconnected fashion. You operate locally—everything you do works. Your inputs are just waiting to go to the other people.
在我们的系统里，有一个叫做命令处理器的模块，负责翻译JavaScript的动作 ，然后传送给数据模块。这就是我们如何在点对点的模式下把数据发送给其他所有的客户。与SOAP不同的是，后者是发送一个请求，然后等待一个HTTP回答，而我们有一个叫做虚拟消息队列的东西。你发出一个命令，发送，但是不用等待回答，因为这是异步的。这就是为什么系统可以运行在离线状态下的缘故了。你完全在本地操作，你的所有操作正在等待发送给其他的客户。 Let's say three peers are in real-time connections to the Internet. One guy draws a sketch on the screen. A stroke comes in from the UI, gets packaged up in XML, and our command processor intercepts it on its way to the data model. It hasn't even impacted the underlying storage yet; it just got interpreted at the UI. The message queue splits your updates, one for B and one for C and off they go. Similarly, if B and C make changes, they're reflected on everybody's screens.
让我们来看这样一种情况，有三个客户同时连到了Internet上。其中一个家伙在屏幕上画了一笔，于是从视图模块传来这个动作，包装成XML ,在传往数据模块的途中先由命令处理器进行翻译。这时还没有影响到底层的存贮对象，仅仅是进行了翻译。消息队列接着把你的更新操作分别发给B和C,两个互不相干。同样，如果是B和C做出了修改，也会反映到所有人的屏幕上的。 Off-line activity is a bit more challenging. If B goes off the Net for a moment and makes a change, he can't get to A and C. He keeps making changes and they keep stacking up in the outbound queue.
对于离线的情况就比较麻烦了。比如B断线了一会儿，与A和C失去了联络，并对屏幕作了修改。 他不断的修改，这些变化也在不断的往出队列里写。 Gillmor: Are these changes serialized to the outbound queue?
Gillmor: 这些变化是按顺序发往出队列的吗？
Ozzie: Yes, and there are optimizations so that when you're editing text and things like that, they're grouped as opposed to having a gazillion keystroke changes. With a Discussion, you'll generate one delta for the whole discussion document; an outliner generates one per line, a chat, one per character.
Ozzie: 是的。事实上，你可以根据实际情况做出优化。比如，在编辑一个文本的时候，就没有必要每按一个键就发一个消息，你可以等到一定时候再集结为一个消息发出。对于论坛，也是类似的。 Gillmor: Can you roll back through that?
Gillmor:可以回溯操作吗？
Ozzie: Yes, the only way you can really architecturally support multiple people in groups working off-line is if to roll back, insert changes, and roll forward again. Unlike Notes, this isn't actually a replication architecture. This is a distributed-transaction architecture, where transactions must execute in a certain order and that's how everything eventually synchronizes. But transactions can be rolled back, and they get meshed in a deterministic fashion. Conflicts that happen are actually data-model dependent: a sketchpad might see two lines over each other and say, "this is okay, this isn't a conflict," and just let it happen. A layout program for a PC board might see two lines intersecting and say, "uh-oh, we have a short circuit here and there's a conflict."
Ozzie: 可以。事实上，如果要在系统结构层次上支持多人的情况下的离线工作，则必须能够回溯操作，加入新操作，然后再重新执行操作。与Notes不一样的是，它不是一个数据复制的结构体系。这是一个分布式事务结构，事务必须按一定的顺序之行，以保持同步。但是事务是可以回溯的，就是可以恢复到事务执行前的状态，而这是那些直线型的模式无法做到的。如果发生冲突，完全取决于数据模型。在书写板里，有两条直线发生重叠了，不会有什么问题。但是，如果是在PC机的电路板上有两条线重叠了，那就是短路了。 Gillmor: How do you negotiate the merging of documents that are updated by on- and off-line people when they all come back on-line at the same time?
Gillmor: 如何合并在线用户和离线用户的文档？他们分别都对文档做了修改，而且现在都连到了线上。
Ozzie: The document engine—data model, it's the same thing—can know that two people have modified the same document, and the app can tell the engine some policies, like keep both of the updates, or let the latest date override.
Ozzie: 同样是文档引擎(就是数据模型)，知道有两个用户对同一个文档做了修改，并根据程序设定的规则----比如，保持所有的修改，或是用最新的数据覆盖旧的----做相应操作。
Getting back to our example, let's say C makes a change. C is still connected to the network, so it can get a change all the way to A—C and A are actually in sync, but B doesn't see it. But, instead of C holding this update in its outbound queue, we actually have this thing out in the network called a relay service. It's like an SMTP relay, a queue of XML messages that are intended to go from one system to the other. One guy could be in Hong Kong, another in New York, and they never come on-line at the same time. So, we use a hot-potato routing to get it as far out into the network as we can.
仍以前面的例子为例，C做了 修改，因为它还在线上，所以可以把所作修改通知给A----所以A和C事实上是同步的，而B这时候却收不到更新消息。实际上，C并不把要发给B的更新数据一直留在自己的消息出队列里，相反是传到网络上一个叫做中继服务(relay service)的地方。这是一个类似SMTP中继一样的东西，保存着从一个地方传到另一个地方的XML消息序列。这样我们就可以让两个分别在香港和纽约，并且从来不同时在线的人，相互合作----通过这种一个接一个的中继服务，达到联系整个网络。 Gillmor: That sounds suspiciously like a server?
Gillmor: 这好像用到服务器了吧。
Ozzie: Oh, it is a server. Groove operates without it, but the quality of service in a disconnected fashion operates better with it. We run a set of these servers. We'll also sell some of those servers so people can do it themselves.
Ozzie: 是的，的确是服务器。但是你也可以不使用它，只是在离线状态工作的时候，性能有所损失而已。我们已经运行了一组这样的服务器，而且还可以对外出售这些服务器，如果有人愿意自己做的话。 Gillmor: It's a caching mechanism.
Gillmor: 这是缓存机制吧。
Ozzie: It's like a router with a disk. It's literally like an SMTP relay. Updates move through it, and the high-water mark of how much storage you're using depends on how long the recipient has been off-line. When you download the product, every user will get a default quota in megabyte minutes or days or whatever, so that they can get a taste for what [the enhanced performance] is like. And we'll offer a higher quality of service—if you really want to buy a gigabyte worth of buffering, we can offer that to you. But if you're using Groove in mostly an ephemeral fashion, you won't need the service. If you use Groove a lot with people on the other side of the globe, you probably will need it a lot more.
Ozzie: 这是一个带硬盘的路由器，很像SMTP中继(转发)。更新消息通过这个服务来进行转发。至于你需要多大的存贮空间，完全取决于数据接收方离线时间的长短。当你下载Groove后，每一个用户都会有一个缺省的空间定额。如果你愿意付费的话，我们可以提供G字节量级的数据缓冲服务。如果你使用Groove的时间很短，就没有必要使用这项服务了。但是如果你经常要与另一个半球的客户打交道的话，你就得经常使用这项服务了。 In a low-speed dial-up situation, we can use the relay service as a proxy. It auto-detects the bandwidth so that one copy of your information goes out and gets forked out when the bandwidth improves. Another function is firewalls and Network Address Translation (NAT) boxes. If A and B are in different organizations and you can't set up a direct peer connection between the two, the relay service can act as a proxy. The proxy holds the messages for B who then pulls the data in through the firewall.
对于拨号上网这种低速连接的情况，可以把中继服务当作代理服务使用。它自动监测带宽，以在数据流量较小的时候传送数据。还可以当作防火墙和网络地址解释器(NAT)使用。比如A和B分属于两个不同的组织，不能直接建立连接，这时候中继服务就可以当作代理，先由B发给中继，中继再发给A。 We wanted to have browser-like simplicity in terms of using the product—no configuration of ports or your IP address, or what your ULS server is—we just wanted it to work. And we wanted it to adapt to the topology that you have, so if you happen to be behind a corporate firewall or a NAT, it just works. If I happen to have a dial-up connection, it just adapts. We don't have to have a PKI, you don't have to get a VeriSign certificate—the encryption is more of a peer security model. We wanted to give this illusion of transparency—peer transparency across the whole Internet, no matter what the topology happens to be.
我们希望这个产品像浏览器一样简单易用。你不需要设定什么IP地址和端口号，也不用管你的ULS服务器是什么。无论你的网络拓扑结构什么，是不是处在公司防火墙或是NAT的后面，都没有问题。是不是拨号连接，有没有PKI，用没有用VersiSing认证(一种点对点的加密模型)，你都不用关心。它会自动工作的。 Another hard problem that we are trying to address in a transparent fashion is the fact that people use multiple computers. We want to make sure that we are building a product where peers are actually people, not necessarily devices. If you use a laptop, a desktop computer at work, and a desktop computer at home, you can still interact with the same people interchangeably—and use your devices interchangeably without having to worry about synchronizing. The same mechanisms that are used to synchronize spaces with other people are used to synchronize your devices with one another very transparently. And we want to handle the flip side of that same coin—a device working with multiple people on it.
另一个我们要解决的问题就是一个客户使用多台计算机的情况。该系统把一个节点看作一个人，而不是人所使用的计算机。比如，你在公司的时候使用的是一台计算机，回到家后用的又是另一台计算机，你仍然可以 保持与同样的人联系。在两台设备之间，你不需要考虑什么同步的问题。该问题和前面提到的与别人同步共享空间是一样的。甚至，还可以同一台设备有多个人使用。 P2P and A2A
Ozzie: Groove developers generally won't be building a pure peer app. They will want to figure out some way to use it in conjunction with the other systems that they've built. Let's say that I'm an engineer at a company that makes airplanes, and we're taking a 747-400 and stretching it to be a 600. We're making bigger wings and I have engines I have to mount on those wings. I go to my GB Aircraft Engines' extranet site to open a new support incident where I can talk to the GB engineers about how to how to mount this engine. GB has told me that they would like to interact with me in Groove. They could have done it via normal Web technologies, but people have to be on-line at the same time and that restricts the interaction to what you can do either in a chat or by talking to each other, or what you can do through a Web form. The intent of using Groove is to make that interaction a lot richer between the engineers who have to work together. I press a button on the extranet page to connect with my designated GB support engineer. This takes a little bit of XML and shoots it down to Groove running on the same machine. A new shared space is created that takes my customer name from the Web page. I can select the type of engine that I have an issue with, and say "I am trying to design a new wing—need engine-mount help—please contact a.s.a.p." Then I can select from one of my designated support contacts, and submit a customer-support request. My GB support engineer gets an invitation and accepts. Remember, this does not have to be happening in real time. It might be more critical that I connect with the right people. If this support engineer realizes he's not the right one to deal with the problem and he needs to escalate it or he needs to bring other people into it, he just invites whomever he needs from GB or wherever to help resolve this problem. When the Groove app was instantiated, it used SOAP to query the GB in-house central system and prepopulate this space with things related to that engine. The support engineer didn't have to manually go and pull things down. Probably the most critical and interesting thing about this app, though, is that the designer of this support app—the IT guy at GB—doesn't know all the support issues that are going to come up. The engineers on one side can decide to do some collaborative design using a CAD tool, and the other guy could bring some files into the space. They can look at a wing assembly in parallel with the same CAD tool—the support system needn't be involved. Furthermore, because the people who built this Auto-CAD app had good APIs on their components, we wrapped it and turned it into a collaborative environment. Auto-CAD didn't know that we were going to build this kind of environment, yet we don't have to build all the data types. And, finally when we're done with this support incident, I can close it and say "Needed engine-mount help—fully resolved." Groove uses SOAP to push the results back up to the Web server, updating the status on the extranet site. You wouldn't necessarily want to build a transaction system in peer technologies. The vast majority of the uses of Groove by business will be something where you have a centralized system that's built on Web technologies, and you're trying to build a highly interactive layer on the outside of that system that adds a whole new dimension to that centralized system. Bots
Gillmor: Do you think that anyone would find it useful to run Groove applications as a component within a browser?
Ozzie: I tend to think not. I tend to think people would rather have a client that gives them navigational capabilities—once they get comfortable with it—that are more tuned to that task. But flip this on its head—I really do think ubiquitous access to information is an issue. There may, indeed, be people with whom you want to interact in this support app that don't have Groove—who are using it at a kiosk or something, and don't want to get those bits onto their computer for some reason. For that environment, there's a completely separate sub-system—a "KnowBot" sub-system. Using the Groove toolkit, you can write things that appear like people to Groove users. You invite them in, but they're actually Bots—server Bots that do systems integration. Let's take the most trivial one—Eliza-Bot—you invite Eliza-Bot in and it can chat with you. One step up, a knowledge-management Bot acts as a benign member, watches the interactions, and archives them into a knowledge-management system. Browser users can look at that information. Let's go to a third level—a more intelligent Bot. I want to know, at any given point in time, from any browser, what the status of the support inquiry is. I don't need to know all the other junk that's going on. A Support-BOT would be auto-invited into this space as it's being instantiated. It would maintain certain aspects of this on the server at all times in the central database so that people from a browser could look or even be able to interact. That is going to be a much more common integration of the browser and these technologies. Gillmor: Bots are basically communication mechanisms back and forth between the browser and Groove?
Ozzie: That's right. It matches the browser paradigm—page-oriented, site-oriented, form-oriented paradigm—with Groove, which has a much more interactive paradigm. It's an impedance matcher between one paradigm and another—take a current image of the sketch and turn it into a JPEG or a GIF that users can download, because they don't have the components, the client, to do so. Gillmor: Are you emitting DHTML from the Bots?
Ozzie: The current Bots are very simple; they write in to a database that ASPs render as normal HTML. But they could download a Java or Active-X component to that client to do a specific type of thing . . . Gillmor: Then you're almost back to the full Groove client anyway.
Ozzie: Exactly. Gillmor: What messaging infrastructure are you using to deliver the invitations?
Ozzie: Right now, we use a mix of MAPI, APIs, and SMTP when you can't do the MAPI stuff in certain instances. We'll use whatever it takes. If somebody had just a mail infrastructure, not an IP infrastructure, we could also carry sets of XML in mail messaging. MIME is also a possibility. We've got to get out to the marketplace and see what's there. Gillmor: What about compatibility with Microsoft Office—bringing Office docs in?
Ozzie: There are two answers, only one of which is satisfying. First, the unsatisfying answer: we're a great carrier of documents. You're doing a deal and you've got your attorney and their outside counsel—you can use Groove to get people together extremely quickly, in like a minute. But you're not doing the editing in our environment. We're carrying the documents back and forth; you would use a simple document-management tool in Groove to do revisions, check in, and check out. The better answer has to do with certain Microsoft tools like PowerPoint. PowerPoint has a rich enough set of interfaces on its surface that we can make a collaborative presentation environment. You can't edit the PowerPoint presentation—the interfaces aren't that rich—but you can rearrange slides. Gillmor: The Notes team, particularly Mussie Shore with QuickPlace, has pretty much explored the range of possibilities in terms of accessing the internals of Word docs and integrating them in document library applications. It's the "Holy Grail" of Notes. It doesn't sound like you're really that concerned about trying to make that work in this environment.
Ozzie: We've built the platform layer up and up and up. We will begin to scratch the surface of useful tools—deeper tools—as time goes on, as will our partners. Will we get to the point of cracking Word documents? I'm sure we will. Will we have better e-mail integration as time goes on? I'm sure we will. Groove is a newborn and all that that implies. Because of all of the security and topology stuff that's built into the product, the people who are gravitating toward the product right now are people who have problems that they need to solve today in partner-to-partner or business-to-consumer, high-value apps. They have a pain right now because the browser isn't rich enough, and the security model of the richer tools aren't meant for use within the enterprise. They tell us, "We have the supply chain, this partner relationship that's all around EDI—we're thinking of going in the .Net direction, but they don't have communication services." People are still talking about e-mail and they're sending stuff over unencrypted SMTP links. They're getting e-mail messages with 40 layers of left-angle brackets because they're trying to communicate context to one another. With small amounts of work—no infrastructure work, no server-based work—we can have those people working together incredibly effectively very quickly doing exception handling, collaborative negotiation, and design—all the soft side of working together. In B-to-C, particularly in financial services—where you've got an investor or banker relationship—customers either just use the Web and have this little portal into what is up on the financial institution's servers, or they use Quicken and own the data themselves. They've gotten spoiled by knowing the fact that this is their data, not the financial institution's data. The financial institution is trying to reach out—give you the feel that it's your data in your control—to you, your spouse, your estate planner, your financial counselor—all as a private group, securely. This is a great technology to reach out in that direction, and provide apps that integrate tools with Excel and other clients that give you a better sense of interactivity. And they don't have to build additional infrastructure. It is very costly to build rich things with n hundreds of thousands of clients, especially when each client has a different mix of tools based on what they do. XML
Gillmor: Why did you choose JavaScript?
Gillmor: 为什么选择JavaScript？
Ozzie: When we build apps, we have to choose a language—we didn't want to build one. We could have used anything—C++, VB, JavaScript, VBScript, Java. We use JavaScript because it's easy to hire Web programmers who have done JavaScript. They're probably the most available, and ECMAScript is portable to the other players.
Ozzie: 当创建一个程序的时候，自然要选择一种语言，我们可不想自己来写一个。当然，我们也可以选择C++,VB,JavaScript,VBScript和Java等等任何一种语言。选择JavaScript是因为这样的程序员比较容易找，因为许多Web程序员都用过JavaScript。而且，ECMAScript是可以移植的。 Gillmor: What's the XML value proposition? You've said it a lot . . .
Gillmor: 使用XML有什么好处吗？你已经提到很多遍了....
Ozzie: . . . about a hundred times. This is a product that's born on the Net and born with XML. Let's start with the app-development side. The paradigm of the product is like the Web—you go there to do things, go somewhere else, and go somewhere else. We must have a persistent store so that you can store tons of data—and we just maintain it. What you're viewing when you go into the app is a small bit of that data. We don't want to go in, open a ton of files, and read them in. We need a database underneath it.
Ozzie: 哈哈，有一百遍了吧。该系统诞生于互联网时代，大量使用XML 。先从程序开发的角度来说吧。与Web一样，你需要在不同的地方使用这个系统。所以我们必须有一个存贮系统来保存和维护数据。对于程序里，你看到的是数据，只是一个小小的部分。我们可不想为了读取这些数据，而要打开一堆的文件。在系统的底层，有一个数据库系统，方便我们的数据存贮。 App-development-paradigm people are getting very comfortable with dealing with XML at a programmatic level. If people are going to become more and more familiar with data representations in XML, then we should build an object store that, at its birth, is very adept at persistent handling of XML. So, we built this storage system that has APIs that are XML semantics. Underneath it are various service providers, one of which lives on XML files in the file system, one of which is an XML-object store, one of which is a ZIP-file store, and one that is multi-part MIME. 应用程序开发人员比较习惯于使用XML。因为人们越来越习惯于用XML来表示数据，所以我们必须创建一个存贮对象，该对象必须能很方便的存贮XML数据。所以，我们存贮系统提供了专为XML提供的API。在底层实现中，可以是XML文件、XML存贮对象、ZIP文件，MIME编码包。 The persistent tools sit on top of the object store get better performance and robustness, so that if you have to "control-alt-del" you don't lose anything. Remember, we don't build on a document paradigm. Every tool has its own data model. We want to make sure we are building on an environment rich enough to define new schemas and data models, and still store it in an object store. On the communication side, we need to get little pieces of information from one machine to another. It's much more convenient to package commands in XML in the controller layer and route it over the wire [than use something like CORBA]. You don't have to worry about layers and layers of software to pack and unpack. It's a little bit fat, so we compress it with WBXML to remove the redundant text information, and then encrypt it. It's a great, flexible description environment when we don't know in advance what the platform is going to be used for. And because we have all these XML services available, it's the representation format of choice throughout the app—for everything we do. Gillmor: What is the mindset to become a Groove developer—it doesn't sound like a VB environment, or a procedural programming environment?
Ozzie: No, the most similar thing out there is probably a component architecture like Mozilla XUL. You really have to be familiar with the concepts around component software and building modular pieces of software that connect to one another. Gillmor: Are Groove developers writing XSL—creating schemas as part of that development process?
Ozzie: Most definitely, they're creating schemas that are relevant to the representation. For example, a V-Card—we call it a contact engine—is a data model that's adept at storing contact information. We use a certain RFC to convert the V-Card schema to XML. Then, another data format is an abstract collection of V-Cards. Put them together and suddenly you have a little contact list. These are layered data models, so to speak. You figure out the schema of what you're adept at, you create an interface for that particular schema, and you render that functionality into the system. It's a formalized component model. Schemas will evolve over time. There are certain public schemas— V-Card is a good example—that we didn't have to define. It's already an RFC. There's an XML schema for vector-graphics—SVG—and XHTML for Rich Text. You would choose the data model based on some requirement, and roll your own if there isn't one. Gillmor: Any thoughts about communicating between your Instant-Messaging format and the Jabber format?
Ozzie: I have a much simpler answer than that. We would delete—or move—onto a different Instant-Messaging format as long as it's one that we can all agree on. I like Jabber—it's an XML switch that's a lot like our architecture. They've gone one step above just Instant Messaging and defined a framework on their server for integrating multiple messaging systems, and defined where you put in translation layers. But I don't know if that's going to be the survivor in the Instant Messaging wars. When they get their act together, we'll put that Instant Messaging in ours. If somebody else's product supports an API, we'll connect at that level. If AIM or ICQ had a good API where I could just drop an attachment on your Buddy List—it sounds good to me. Gillmor: So, your strategy is to use your client and these tools in concert rather than trying to integrate into existing groupware tools?
Ozzie: Oh, believe you me, we will integrate with the existing tools. I want to integrate with AIM and the others because they're going to be there. We just have to convince them to have integration points.
Steve Gillmor is the editor in chief of XML Magazine. He can be reached at [email protected].
注：突然在一个角落里发现了这篇文章，现在再看，还是有很多的启发。 |
