Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ll-xn!ames!ucbcad!ucbvax!ZERMATT.LCS.MIT.EDU!RWS
From: RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler)
Newsgroups: comp.windows.x
Subject: Re: 128k request limit
Message-ID: <870414083107.2.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Tue, 14-Apr-87 07:31:00 EST
Article-I.D.: KILLINGT.870414083107.2.RWS
Posted: Tue Apr 14 07:31:00 1987
Date-Received: Sat, 18-Apr-87 23:45:27 EST
References: <8704140212.AA20120@ucbarpa.Berkeley.EDU>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 26


	    At the risk of invoking your wrath, I would like to ask one
    final question about the maximum request size.  You mentioned that

No wrath from me, I'm happy to answer questions as time permits.

    > Libraries (and perhaps applications) will have to be designed to deal
    > with a run-time controlled maximum size.  Large images will have to be
    > sent in chunks.

    Does that mean that X11's equivalent of XBitmapBitsPut and similar
    functions will automatically break up the data into chunks that are
    smaller than the (server's) maximum request size, or will the users
    that call X11's equivalent of XBitmapBitsPut's (and similar functions)
    have to do that, and if so, will a function be provided that will
    return the maximum request size?

There will certainly be a function that returns the maximum.  As to the
rest, I'll leave the definitive word to the Xlib designer (and prod him
for a response), but I certainly believe there should be routines for
the image requests that break data into chunks, so that callers don't
have to keep reinventing this wheel.   It's unclear whether the
"standard" interface should generate an error on oversize data or
decompose, since the latter does change the semantics with respect to
indivisibility.  Note that the same sorts of issues can also arise in
other requests (e.g., most of the Poly graphic requests).