In <bitnet.adsm-l%199511132053.PAA12138 AT wood.helios.nd DOT edu>, dboyes AT 
wood.helios.nd DOT edu (David Boyes) writes:
>>Firstly,it took an extremely long time to return a large list from the server.
>> We had several customer requests to reduce this time.
>
>True, but on a large server, you'd expect it to take a
>considerable time.
>
>> Secondly, a decision was made that such a large list (500+) was not useful.
>> Again, this decision was based on customer input.
>
>Returning incomplete information is even less useful. I have well
>over 600 clients at one installation. Returning the first 500
>doesn't do me any good if I want to manage the last 100.
>
>> If this compromise is too restrictive, I would be happy to pass on your
>> comments to the development group.
>
>I'd say it's seriously broken. If you must limit the size of the
>transfer, at least give us a button to say "I Want It All" and
>that we're willing to wait, similar to the wait for offline media
>dialog. That'd probably be a good compromise -- queries that are
>likely to take an extended period -- say over 300 lines of output
>or so -- could trigger a "this is a big query, do you want to
>wait?" box. Of course, you'll need a setting to be able to say
>"yes, always wait"...

I know that I have complained more than once via PMR's and suggestions
about this problem (returning too many nodes, etc.), but I never suggested
an arbitrary limit.  What I always suggested was to pop up the include
window before the server was queried and the initial list was displayed.
Every admin could then limit the display or see the whole list - first
time, every time.


Bill Colwell
C. S. Draper Lab
Email: BColwell AT draper DOT com
Voice: 617-258-1550