1990 Ad

Robert S. Epstein

Esther Dyson, EDventure Holdings: Enzo's going tO come up and talk about client/server computing to kick off our next panel. Enzo Torresi, NetFRAME: Given that I only have five minutes in the spotlight, Esther, I decided to throw this away. Also this morning Stewart disturbed me as I was having breakfast with a friend. He asked, "Are you nervous?" I said no. "Well, every good speaker is very nervous before a speech," he said.

[Laughter]

Then he asked me, "What are you going to be talking about?" I said client/server architecture. He looked at me and said, "Boring, huh?"

[Laughter]

Then we walked in here, and Bob was flying at an elevation of 40,000 feet, telling us that operating systems arc irrelevant. As of last week, I've been flying at 5000 feet looking at every little tree in the jungle. He said, Well, Enzo, get resigned to the fact that you are a Ph.D. from Italy and Bob is a Ph.D. from the US...

[Laughter] ... and I just don't know what to say. Do we go immediately to application servers in vertical applications? I thought this issue in general, whether we go horizontal or vertical first, is probably like sex. By necessity, you have to go horizontally first before you can go vertical.

I looked at how truly passionate we are with these operating systems debates, and I thought David's stuff on the client side of the software was wonderful. But on the server side' we're trying to build a universal server. I call it the Switzerland of servers. In all honesty I have to tell you we are not operating-system independent. Every one of our partners on the software side is extremely passionate about whether our world is going to be OS/2-centric, NetWare-centric, or UNIX-centric.

In all my simplicity, I'm trying to look at the client side where I have four prevailing operating systems for sure: DOS, OS/2, Mac and UNIX. I look at the server side where I have at the minimum three dominant platforms: OS/2, NetWare and UNIX. Then I draw this grid of possible combinations, and I'm convinced the hardware is here today. That's the good news.

The bad news is we have to energize software developers to develop aggressive, interesting and creative client/server computing applications. Interoperability is wonderful, but it's a dream. It's not here today. Today we're dealing with such mundane proletarian issues as whether Macintosh will connect at all to the server, and how we're going to support NFS files at the same time we are running OS/2, LAN Manager and LAN Server on the server side. If I can make one point to take home, it would be to find out through the panel today which of these environments is going to prevail and which platform applications developers should concentrate on first.

There's no question in my mind that ultimately we want to make it totally customer-transparent. But from the point of view of where we are today and where we're going, it is not a transparent decision for developers.

Let's be realistic and maybe let's try to learn from the panel which of those environments will prevail. Attractiveness is strong on all sides. I can argue why Oracle Server and NetWare will be great. I can argue why SQL Server will be great on OS/2. But I can also argue all the reasons why we should have a powerful UNIX engine in the back-end first. SQL technology is fundamental, but we have at least three choices. UNIX technology is fundamental to client/server computing, but it's very hard to decide which will happen first. Before we go vertical, we probably need to go a little more horizontal and talk about it. Thank you.

[Applause]

Dyson: As Bob Berland said, "Where it is horizontal, what is it, cooperation between consenting adults or something?"

Now we're going to have the focus group for Enzo to say which environments you should support first. Just trying to see if everybody's compatible up here. You know Enzo, Bin Gates and Dave Liddle. Mike Zisman runs Soft-Switch. He's the ultimate server-central guy who helps different mail systems talk to each other. He's on the board of Beyond Inc., a competitor of Agility Systems, which is John Landry's company. Then there's Bob Metcalfe and Bob Epstein.

I'd like to start with concrete responses to this issue. Everyone thinks a client/server architecture is okay. You've got the database here, SQL is in the middle and the application is on the other end. That's an implementation, but it's very far from being the whole thing. As Danny Hillis or someone said, it's like calling - what was it, non-elephant zoology? Oh, hen, I'll get it later.

There's more to client/server computing than databases and little front-end apps, spreadsheets or tools that take data onto the database using SQL. The question is: What should be on the client and what should be on the server? On one extreme there's nothing on the client. Then some people say the user interface should be on the client and an the processing on the server. Starting with Bob, what should be on the client and what should be on the server? What are the factors that determine the appropriate breakpoint between the two?

Robert S. Epstein, Sybase: That's somewhat application-dependent but the biggest breakpoint is where control has to be managed. The control is easier to administer from the server than from the client so things with the highest value to the overall enterprise have to be in the server and controlled there. That's one metric to use.

Dyson: In a sense you're talking about maintenance and consistency. You can do what you want locally, but you want to protect the - Epstein: Right. Think of the data as money. We have petty cash accounts, and we can do a fixed amount with them. For a higher value, we have to go to higher authority. So the higher-value data has to be controlled by servers.

Dyson: As do some of things you can do to the data. The transactions or the methods you store on the server may say you can't take money out of this account without putting it somewhere else or you can't send someone a ticket without charging someone's American Express Card or

Epstein: Correct.

John Landry, Agility: I think I agree with Bob, but there are some massive client/server computing problems that haven't been solved yet. Even if you agree most business functions of client/server architecture belong on the server side, and the client side predominantly handles the presentation, an inevitable problem still exists. If you change the server, how does the client know it's been changed? That software application problem of how that synchronization occurs has not been resolved by anybody as far as I know. A friend at this conference asked me, "Do you know of any tool kits that solve this problem?" My answer was, Yes, but I don't think you'd want to use them." Until somebody cracks this nut, there are significant software-engineering problems in client/server computing, let alone multiple-distributive database problems which we'll probably go into later.

Robert M. Metcalfe, 3Com: The term client/server computing has a 15-year history which deserves a talk like David Liddle just gave on user interface. Since we don't have time for that, the current usage of the term - to put a very fine point on the stick - is that the server is open. There have been servers for more than five years, and they're becoming open. The server network operating system is becoming part of the operating system and the programming tools for developing applications extend not only to the client but also into the server. Not only SQL, but also many other server side applications can be developed. Not just by the network vendors, but by application developers of which there are thousands. They'll decide what belongs on the server and what belongs on the client - Dyson: What factors will they use to make that decision? What belongs where and why?

Metcalfe: They'll answer that question. Michael D. Zisman, Soft-Switch: What allows us to move toward client/server computing is a definition of a clear, agreed-upon protocol for communication between the client and the server. It's SQL. I'm not a database person; SQL may be a great protocol for database or a terrible protocol for database. It really doesn't matter. It's the protocol today by which clients know they can communicate reliably with a server.

In the mail world there's a clear delineation between clients and servers, very much along the lines of SQL. Unfortunately we have four protocols for client/server communication: SAA, TCP/IP, X.400, and the LAN-based MHS. I have what may be a trivial answer to the answer of what belongs in the server and what belongs in the client. But it's a good starting point: Those things that are cross-client belong to the server. Those functions that are not - that are specific to a client - don't have to be in the server.

Dyson: Thanks. That's a start. David?

David Liddle, Metaphor. As is so often the case with these things, the definitional issues are tougher than the problem itself. These are abused terms. To go along with the gag for a minute, let me tell you the definitions - which you can accept or reject - that I use to talk about these things. First of all, in my book servers don't execute applications. They provide services. Applications occur in two places: on machines I can workstations or pcs and on machines I call hosts. Okay? So if an application is doing a business-specific task for a user, I say it is either on the workstation or on the host. Services are well-defined from my point of view. They're generic functions where there are economies available because of a regularized single-function approach, like getting records out of a database, getting file pages or putting packets out on a network.

Servers are very specialized dumb brutes, not a pool of general-purpose MIPS that you can go out and grab for your workstation when your memory seems too small. In general, hosts and servers are different, although the same machine, if it's big enough to be a good host, can also provide some services at the same time. But it's important not to confuse those two. And, with due respect to the perfectly valid marketing term "network operating system," which 3Com and Novell and others use, I agree with Bob Epstein that networks don't have operating systems. They have protocols. Okay?

If the protocols are implemented properly, we don't really care what underlying operating system is on the network. All might? It's important to focus on that fact. The nice thing about client/server is that if you know the protocol and it's implemented properly in both ends, these two facilities can communicate without knowing a lot of details about one another.

Dyson: In that context, where do you put the Visa server? It sounds to me like an application on a server.

Liddle: That depends on what it's like. If it's a transaction that it processes there, which I suspect it is, then it's a server in my view. Okay? But the only reason I say that is that if it can be reduced to a service, all right. I don't object to the idea that servers have advanced functions. It isn't that they just do trivial low-level transactions, but as Mike Zisman said, it's that they arc cross-client capabilities.

Dyson: So the notion that you talk to them using specific procedure calls is probably too formal a term. You ask for specific things to be done, and you have to muck around in the server from the client.

Liddle: Right. If you ask it, "Please run this whole application for me," I call that a host.

William H. Gates, Microsoft: In the client world, you clearly want to have the interface down on a client, and the shared data up on the server. What's left over is the processing. For any protocol you're basically choosing whether that processing is up on the server or down on the client. For particular applications, say data management, you've seen different approaches. Products like DBASE and R:BASE did support multi-user capabilities using file-system protocols, which then are called locking, to coordinate use of the shared data.

Why are we doing aU this SQL stuff? Why wasn't that adequate? Well, that puts the split of processing very much down in the client. It means that if you're traversing a large database, a massive amount of data has to move down onto that client. And as Bob mentioned, it also causes problems with the procedures that control access to that data. If you use those file-sharing protocols, your granularity of control very quickly becomes at the file level. So we have a contrast between the file-system, record-locking approach vs. SQL. For significant applications, most people are going to the SQL approach because there were performance and security problems with the other.

We have the same contrast in the mail area. There's one from Consumer Software called AAPI; there's one called MHS message-handling system - which uses the file system. Therefore it has problems with security and things that should be done by the server. The other approach is X.400 where there are a variety of protocols that determine how you split processing between the client and the server. That's difficult because as mail gets richer, you have to keep enhancing the protocols. it's hard to do the split when the nature of the application keeps changing. SQL databases are relatively static.

Torresi: Esther, I didn't think this was that complicated a question. We're making it complex. If you look at what the client does well and what the server does well, it's obvious the client does the user interface well. The client tends to be MIPS-intensive and uses MIPS well. We saw the wonderful things David showed us and they are good for long-term direction. What the server does well is storage. Clearly the SQL engine is going to stay on the server. How that line moves, Esther, is an even easier question. That's dictated by the economics of today's technology.

It's going to tend to be light clients and heavy servers. By that I mean initially we'll see even DOS clients connecting to very powerful engines on the server side. As we evolve we'll have more powerful clients with better graphical interfaces and aU of that. In my definition, the host and the server are going to be the same thing. I also believe very strongly it is going to drive in the direction of heterogeneous environments, where there's no need for the client to run under the same operating system as the server.

Dyson: We're getting hardware and virtual software and things like that mixed up, because one man's client can be another man's server. I'd like John Landry, who has thought a lot about this, to take this point - and Bob Epstein and anyone else who wants to chip in. It's not that simple, unfortunately.

Landry: I'm going back to what Enzo said. We heard about the interface and heard about the database, but where did the application go? There are severe problems - I'll bring them up again - with how you synchronize those two things. Okay? If the data passing the messages between the client and the server is going to change, somehow that client has to reflect that change the next time it's executed. This is not weB done. When I was at Cullinet we encouraged everybody to build a production client/server application. But the way to handle that software-distribution problem was to hire Robert Morris and you got the software whether you wanted it or not...

[Laughter] ...but until this is handled, we're oversimplifying this problem. Furthermore, as Esther said, it cascades. If I send a message from a client to a server and that server determines it has to send a message to another server, we've got the same problem all over again but repeated again in the software-distribution side. I'd like to hear what Bob thinks about that. Client/server computers are not going to take off very quickly, at least for robust production-grade applications.

Dyson: I thought you were supposed to be able to ask your server to do something without knowing how it did it, so you didn't care if it changed?

Landry: It's simple if you change an application. Take an accounts payable system, okay? You're processing invoices in this wonderful graphical equipment on the front-end and your business process for checking whether that invoice should be processed is at the server-end, which then does an SQL-database update. Changing what we do on the server side and how we process invoices requires a new data field to be present on the client. How does that new client system get distributed to all those little workstations - 10,000 or 40,000 of them in Canadian Pacific - and be consistent and synchronous?

Dyson: Bob? Just the client as server and server as client?

Epstein: Not John's question?

Dyson: Well, do you have an answer?

Epstein: Sure. I'll take a stab at it. Well, let me answer both. Whether a piece of hardware is a client or server is totally a function of the software that runs on it and your economics. If a certain class-say a workstation-doesn't meet your requirement as a server, you need a larger workstation or a different class of machine. It's not a machine that makes it a server; it's the software that runs on it. Certainly you'd have a hard time finding a pc with a large 10 configuration and NetFRAME may provide that. That's why you would go that way.

To answer John's question, we put a heavy emphasis on remote,- procedures calls, and so the abstraction of how the processing works is separated. The other thing we do is for certain classes of validation the front-end tools read the definition out of the database and do that validation. So if it changes in the database, the tools are automatically reflected. In the case where new data needs to come in ... we allow the notion of default values. You either say, "Until that application can provide a new data it's shut down." Or you say, "Here's the default value you use if it doesn't come in. Here's how to post them."

If it's the interface that requires new data to come over, the only solution is going to be for the client to talk to the server in advance to know what data is needed and to separate it automatically. That will mean that we need front-ends that increasingly are not programmed by a programmer but rather will look at the server and generate themselves. That will help. I won't claim that we've solved all the problems. I think John's right. We've solved an interesting enough class to make it more productive than to do it another way.

Dennis L. McEvoy, Cooperative Solutions: I have an answer for you, John, but I'm not going to tell you until next year because you're too smart. Actually I'm up here to ask Bob a question. In your presentation, Bob, you showed those servers as separate boxes. Do those represent separate hardware costs? And as the boxes get more powerful, what's going to happen in your hardware server environment as far as having multiple functions run on the same server?

Epstein: The boxes represent logical units of work. They might all be on the same server. They might be on different servers. I was trying to express - and thank you for giving me the chance to clarify it - that this is more the architectural way you think about building your application. If they all fit on one server, that's all you run. If it's multiple servers, that's fine.

McEvoy: Would that be with multiple copies of Sybase running on that one server or is it separate databases on one copy?

Epstein: In that particular example, only two of the servers are built using Sybase. The Seat Server was built using custom software with its own algorithms for how long it win hold seats and the rest. But it used the same interface to talk to it.

Amy D. Wohl, Wohl Associates: In a client/server environment where there are many clients, many servers and many applications, coordination and control are important functions, particularly if many clients are working with the same data and changing it in close proximity. Is the best place for those control functions within the client environment? Should the client be in charge of what's going on, or should the server be in charge? Should that control somehow be passing back and forth at different moments? Or does it belong in a different place?

Dyson: That's almost the first question I asked but who wants - Enzo?

Torresi: The software is going to get so complicated that it's probably going to remain an integral part of the server side. The remote console or the network administrator function will be a window, a screen or a function that will reside with the client. At least that's our approach to it. You add password protection so that not everybody on the fine side can have access to the administration function. I do agree that function is going to get more and more complicated, and where the processing occurs probably will be irrelevant. We see a lot of graphical user interface coming to the rescue in that area as well. That's important, because this is going to get awfully complicated.

Zisman: Soft-Switch is a classic mail server in the sense that no user ever sees Soft- Switch. All sorts of other clients are out there accessing our servers and we've seen these networks grow over the years. Our largest customer has about 80,000 users around the world, accessing about eight different vendors' mail systems. In terms of change it would be absolutely foolish to think that the system isn't changing somewhere every single day.

In terms of John's comments about servers and clients changing - hey, that's reality in a multi-vendor environment. Needless to say, it's even worse when something doesn't work because a customer calls and says, "It didn't work and I didn't change anything." The reality is he didn't change anything, but someone half-a-world away did. What our customers are evolving to is very clear. They figure it out or they say, "God, if you could just make all this stuff out I'd be in seventh heaven." They become a victim of their own success.

Customers want to manage this from a single or a small number of locations. They want to view their entire network of mail servers as a single entity from an administrative standpoint. For a single location, they want a source of alerts and alarms and to be able to tap into any server. Unfortunately you have to add more and more network management protocols at the server's server level when you add tighter version control at the server's client level. So when the accounts payable application changes, opens into a session with a client and says, T want to give you version 3.0 of this protocol," the client says, "No way, Jose. I only know about version 1.2." He either shuts down or says, "Okay. I'll talk version 2.0." There are no magic answers, but network management becomes a key issue in these large networks.

Dyson: I want to try a non-partisan, more conceptual approach to this. It has to do with object orientation and dispersed control and aU these other things. In the end, each part of the system thinks it is in control because much like Bob Epstein's graphs, it thinks it's the most important and the other parts are just services. What that means is each piece has to be designed very carefully so that it doesn't break when called on by the others. But in fact there is no point of control because no part of the system knows about the interior of all other parts.

This is what encapsulation and client/server cooperative processing and protocols are all about. Because I use the protocol I don't need to know exactly what happens on the other end. If you don't do this carefully, you can have disasters. But there's no God there. There's just a lot of individual consciousnesses that see all the other parts of the world as objects.

Bob Frankston, Lotus Development: I hear a lot of different conversations going on here. There are some people who are doing specific network applications, where that interlocking problem occurs. But the more fundamental theme is the decomposition and recomposition of applications. With apologies to

Metcalfe, this idea is not five years old. It's at least 250 or more years old. How do you split up complicated applications, either front-end or back-end, to separate machines and to the same machines functioning in units? Then what's the client/server dynamic relationship?

Ultimately the client is the user getting service delivered with -a van or some other way. The best example was from Esther's newsletter a while ago - the robot with 32 assembly applications.

It takes this program and think's it's providing service to humans. You've got two programs now talking to each other. What we're really trying to do is understand what the protocols are, so without arranging it, applications can cooperate and take advantage of each other. There's a whole history; X.400 is one of them. The protocols of one then become a certain program discussion of database servers. How do we do interlocking?

Then there's a philosophical aspect to this. If we have a complex of services running together, what is the metasystem like? We have to understand these are separate problems. If we keep talking about them as if they're the same, we're not going to get any place.

Torresi: We could probably assume that most of us know the obstacles and the standardization issues in RPCs and protocols. Why don't we assume that and ask the panel which is the most likely environment? If I'm a software developer, I know what these obstacles are and that it's going to take some time for these things to converge. But I wonder, "What is going to make the first interesting client/server application and on which instrument?" This is not a trivial question.

Dyson: Enzo still wants his focus group, so let's give him an answer.

Torresi: Well, we're running out of time and everybody's showing off how well they know the issue. We all know the issue. The obstacles are very clear. We ought to write a book on RPCs. Let's do it today.

Dyson: Okay. Who wants to help out Enzo and give him some advice?

Landry: RPCs are not the issue. RPCs are communications mechanisms between two processes. There are standards developing. If you want a generic RPC, go talk to the Netwise guys. That isn't the issue. The issue is what the application is going to do. How is it going to handle data on the other end? How is it going to handle transaction-processing stuff from mainframes on the other end? Those are the big issues. RPCs are a pipe - Dyson: Enzo really wants some advice. Enzo, ask your question in specific ways so someone can answer it.

Torresi: Okay. First of all, the impact of client/server computing is the arrival of possibly very creative client/server applications that go beyond current client/server applications like electronic mail, document processing or simple file-server applications. Let's envision the Visa server in a similar way. I'm using Excel today. I'm using Lotus. I'm using word processing. I want to have easy access to data on my server in human language with a very easy graphical interface. It might be on my host. It might be on my mainframe. I pull down a menu and in plain English I request information.

I don't know how I do it exactly, but I get the information back through a process or an application, which brings it back into an application I'm already using that I'm comfortable with. Can I do that today? No. Is that incomprehensibly complex to do? I don't think so. I have talked to a lot of people who are working to make very simple front-ends that will be embedded into existing applications people use a lot today. That would eliminate a lot of this double-entry stuff going on everywhere, where we play with menus and end-user systems on one side of the desk and on the other side have access to our real database on the mainframe. That's ludicrous if you think of pc utilization. Could that be done? I believe it can be. I don't believe it's so esoteric and complicated.

Dyson: it's being done by a lot of people, but unfortunately they're all doing it differently. The purpose of something like SQL is so they can aH at least get data off a common database. Unfortunately when you start talking about application-specific stuff, you want more than SQL going back and forth.

Gates: If the only client/server thing you want is getting into these very homogeneous SQL databases, then the evolution of the SQL standard will take care of that. Then there are the extensions, such as DataLens from Lotus or DDE in Excel. They're architectures within the client environments and can reach out to any SQL database and be independent of whichever server you're dealing with. If you think client/server spans more things like mail or - let me take a different one - printing, there isn't as much uniformity. That's what forces you to pick a server, whether a NetWare server, an OS/2 server or whatever server is going to be better for you.

In the case of printing, it might he nice when you've said to print something, that instead of any work happening at the workstation, the file was simply printed by the server. But that would mean the part of the application that knows how to look at that file and to print would have to know how to run on the server. That's an example where uniformity between a client operating system and a server operating system is very advantageous. If people want that, then they would look at popular client operating systems.

Dyson: Such as OS/2?

Gates: Yes, frankly. This is OS/2.

Dyson: Okay. Bob Berland, let's try something completely different.

Robert F. Berland, IBM. I've got a different problem. We talk about client/server as if the client is a person. I travel so much that what I need is some work done on ancient architecture that can bridge the gap between these diverse systems. I need something that can act in my behalf with heterogeneous environments that couldn't he planned a priori and have to be dynamically adaptable to the addition of new clients, new requirements and so on. I'm worried we haven't put enough effort into what I'll call the "ease of use" of building those agents and making those agents accessible to the client who is a person or a process or a server. This is the area that's going to open up more opportunity for all of us, because nobody's going to solve everything and we're not an going to agree on everything in this decade.

Dyson: Thank you. Ut's try and just run through the questions without answers quickly, starting with Scott.

Scott M. Smith, Donaldson, Lufkin & Jenrette: Can anyone suggest a probable combination of operating systems, applications, networks, client/server versions, whatever, that win have a negative scenario for Microsoft over the long term?

Dyson: He's a securities analyst. You can tell.

Smith: And if they can, Bill, respond to it.

[Laughter]

Dyson: I can't resist this one. Go ahead, John.

Landry: Since I opened it up with distributed database, I might as well say what it is. As client/server moves on, the database is going to be the most critical piece. In distributed database, it's going to be the architecture. IBM owns the mainframe database market with DB2. IBM certainly owns the AS/400 database market. They have a database manager for OS/2 in the new version that should be much better than the current version. Allegedly they're working on a UNIX-based dbms. Bob over here has a wonderful database, and we can talk about Oracle. But the deal is distributed database, which architecturally is a very, very tough thing to do.

It requires protocols for coordinated commit, meaning logic for committing a transaction between multiple databases and multiple servers. That is a very tough thing to do. If we could only solve that problem, then we could maybe play IBM's distributed database game.

From my perspective, IBM could make a big push, particularly to their big installed base of DB2 customers, and more or less lock up the distributed-database market by keeping their protocols closed. If IBM could take more of the database business, the threat is not as great to Bill as it might be to Bob, but it's still an interesting scenario. IBM could redominate the whole pc, client/server architecture by providing this distributed-database architecture and locking it up with closed protocols.

Dyson: This is interesting. As I mentioned, we've had this whole conference assuming IBM dominance.

[Laughter]

Maybe we took it for granted. I don't know.

Torresi: I don't think that's a bad scenario for Microsoft. I have a hard time envisioning a bad side for Bill because IBM stated publicly that they will unify LAN Server with LAN Manager. In fact, they have talked to us about getting LAN Server from them direct - or from Microsoft - effective in July. That's a reality. As far as the Extended Edition of OS/2 which would imply the support for DB2 we're talking about, there is some discussion that they might license that technology to the public. That would be the only locking mechanism that would prevent DB2 access other than within IBM systems. That also might resolve into another good scenario for Microsoft. In my view, the only bad scenario for Microsoft is not going to come from IBM.

Liddle: I don't want to say this is a scenario that's bad specifically Microsoft. I'm not sure that's a constructive way to look at it. But there is a situation in the present individual, end-user computing marketplace as it exists today, which doesn't necessarily apply in a client/server world or at least not on the server side. This affects Microsoft, Compaq, NetFRAME and lots of companies. It's very clear why an open architecture and an industry-standard, extensible operating system have been important to the growth of productivity-oriented personal computing. It's very clear why the fact that DOS and OS/2 run uniformly on all these platforms and have the same architecture has caused a thousand flowers to bloom. Lots of applications took place at the time and companies felt confident buying them. Okay?

But the dynamic "server" end is not quite the same as that. The arguments that say either you have to have an industry-standard intel instruction set in a server or indeed that you have to run any particular operating system, OS/2 or anything else, are not yet proved. There are plenty of successful environments in which the servers are VAXes or 68000s or other non-Intel machines and aU that is bidden.

The companies that have successfully written the existing standards will continue to do so at the client-end. But I don't think that's nearly as applicable at the server-end.

Dyson: Can we get Bill's follow-up?

Gates: Let me start with Dave's point, which is a valid one. Depending on how many services you think are necessary, the importance of a packaged-product binary standard may be far less at the server level. Therefore you might have a more split operating system market than you do in the client market, which is not very split. One argument against that be would be that the client operating system and server operating system should be the same. But those things aren't proven yet.

As far as IBM goes, we cooperate with IBM on file-sharing, which is the dominant aspect of networking today. It's starting to include some database work and will include more and more mail work as fundamental services.

If IBM is very strong, our file-sharing or LAN Manager will be very strong. If it's their database from their Extended Edition, then we would not be as strong with our SQL product which we get from Sybase. It remains to be seen how wen that will be established. We're actually very pleased with the reactions we've gotten from people. Oracle is another important player which hasn't been talked about much. Oracle has incredible strength, particularly in the minicomputer area, and it's possible they could dominate pc servers. They're certainly very focused on it.

Dyson: I don't think you need everything to do quite well, Bill.

Gates: Fine. I agree.

Dyson: Exactly.

Gates: I'm optimistic.

Landry: I want to speak on behalf of the person in the Visa bubble in Bob's life because I think we've talked about aU the other bubbles a lot. From a mainframe perspective servicing business events with transactions that sit somewhere between an in-basket and an out-basket, there are a lot of things that happen besides the data entry that we don't support very well. Real client/server computing potential is examples like Visa where the customer's view of the interaction with the architecture is to service the business event. There are these things you call acts or servers to do that for you. We don't want to know about au the rest of the stuff that's underneath the covers. The technology will come in at the point where the protocols fall beneath the threshold of pain of the application developers. We have no balance.

David C. Mahoney, Banyan Systems: I'd like to make one point which relates to a lot of the comments that I've heard here today. We've been in the business of developing client/server applications for six years. Our whole product is based on that model. It's not the hardware that's going to standardize. It isn't the protocols. There will be multiple operating systems for the foreseeable future. We'll all have to deal with those problems as we have for six years. One thing we've done here today - I sympathized with Bob's comments earlier - is to leave the users' concerns out of the picture again. We've talked about the technology and the technical problems, but we have not looked at what the inherent limits will be for any of us to make money on building client/server applications.

That problem is the manageability of the entire market with multiple servers and multiple services. When we first delivered our products six years ago, we had to add a service to keep track of all of the other servers in the network and give the administrator a view of that environment. Until we all start taking into consideration how the services are going to work cooperatively, none of us will be able to build businesses around this concept.

Dyson: Thank you. I want to close this session on what turned out to be strictly client/server architecture by getting the aphorism right. It was: The study of non-linear phenomena is like the study of non-elephant zoology. The point is that client/server databases offer simply the ability to get data in a very regular way. They are the biggest part of the client/server business right now because it's the part that's the easiest to do. But in the future servers are going to serve all kinds of complex transactions, objects, compound text documents, printing services. Come back next year to hear about object-oriented databases and how all that fits in. When you think of client/server don't think just of SQL. Think of two processes cooperating and all the problems trying to keep these guys coordinated and independent. Okay. Have a great break. Thank you very much.

COPYRIGHT 1990 EDventure Holdings, Inc.
COPYRIGHT 2004 Gale Group