RE: Plea for Server Side Sorting

["Mark H. Wood" <mwood@IUPUI.Edu>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 1 Apr 2005, Christopher Hicks wrote:
[snip]
> So the question boils down to: does it seem reasonable for a directory
> service to sort results.  Its hard to imagine a corporate directory in the
> real world that /isn't/ sorted, so for the computer equivalent to be
> designed in a way that doesn't allow for sorting would seem to be poorly
> modeled.

A paper directory has to exist in some sort of order because no one would
use it if exhaustive search were required.  Adding a computer to do the
dull repetitive work means that things do not have to be organized the
same way -- there may be better ways, given that the machines can present
any computable result regardless of what they have to do to produce it.

Ever try to resolve a telephone number to a subscriber name, rather than
the other way 'round?  The telephone book isn't very helpful for that
mapping, is it?  A mechanized directory can do it easily without
compromising its ability to map in the other direction.  Ditto "list all
persons surnamed Mark".  ("I don't remember what division he's from, but
his name is Mark.")

> In terms of considering LDAP as special-purpose database, there aren't
> many databases that don't provide some sort facility.  SQL does.  The UNIX
> command line does.  Mainframes and Minis with the many wacky variations on
> ISAM do.

Which RDBMS products do referrals?  An LDAP server can tell the client,
"go ask That Other Server over there".  That Other Server may not
implement server-side sorting even if your own does.  As long as one
non-sorting service exists, clients which depend on server-side sorting
are broken.

> In terms of IS system design and putting functionality in the most logical
> place, we can have hundreds of different clients sort results or have the
> server sort results.  It seems quite clear that having the server sort
> results puts the code in the fewest places, which naturally leads to fewer
> bugs, is better for programmer's mental health everywhere, and so on.

This argument is compelling when you are looking at a single application,
or even a single administrative domain, within which the division of labor
between client and server is under your control.  Crossing multiple
administrative domains strips away that necessary property.  Directory
services were designed with the idea that crossing administrative domains
would be a commonplace occurrence.  The robustness principle argues that
clients should not be dependent on server features which are not required
to be present.

User-interface design practice also suggests that the client should be
able to sort.  User says, "hmmm, I don't like this order...sort *that*
column instead" and clicks a column header.  Do you make another trip to
the server, or do you resort the control's content and refresh the
display?

- -- 
Mark H. Wood, Lead System Programmer   mwood@IUPUI.Edu
Open-source executable:  $0.00.  Source:  $0.00  Control:  priceless!

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: pgpenvelope 2.10.2 - http://pgpenvelope.sourceforge.net/

iD8DBQFCVBJKs/NR4JuTKG8RAoJrAJ9itZtbfl0PDJzC6U6+NaTzeG3KdQCfU0pu
gX/rksAdtpLq/Ukibr5oBeA=
=jF+E
-----END PGP SIGNATURE-----