CVS update: tng/source/passdb

Peter Samuelson peter at
Tue Jan 8 17:07:18 GMT 2002

[Joe Doran]
> I am a bit confused here. I have always believed that traditional
> client/server services such as http/smtp utilize flat transmissions
> and as as such do not facilitate the extensions of the application at
> the server end?

Not that it matters - it's all just a matter of taxonomy ...

...but no, client/server implies that a server is providing something
to a client, on demand.  There is a specified protocol for how the
client obtains services from the server.  There's no requirement for
the service to consist essentially of flat files.

In the case of http, who ever said the server can't do significant
amounts of processing?  Not all web pages are static, you know.  Same
with smtp - the server accepts mail - and then does what?  We don't
know - possibly operates an ftp gateway, for example.

> Where as RPC's and DCE such as NFS, MS-RPC allow the application to
> utilize the the procedural functions at the server end without an
> overhead on the client?

The whole point of RPC languages is to use a client/server paradigm but
present it to the application developer as a library interface
paradigm.  With RPC you don't "communicate with a server", you "call a
function you've defined which happens to be on the server".

Note that client/server and RPC are to some extent interchangeable -
you can implement an RPC protocol using a client/server paradigm.  This
is more or less what Samba does.  (The converse is a bit harder to
imagine, though.)

> A classic example being ms outlook where minimal processing as such
> takes place on the client, all the mail function takes place on the
> exchange server. In contrast the ms mail client could be considered
> client/server as it utilized mail files on a share and processes mail
> locally on the client.

MS Mail is not usually considered to be client/server, because there
isn't a "mail server" process - just a file server which can be used
for many things outside MS Mail.

Peter, already regretting getting into this thread

More information about the samba-technical mailing list