Variable sized server replies

[Thomas Kho]

In protocol.def, the get_startup_info request declares two VARARGS as
replies. Unless I've mistaken, replies are limited to one VARARG that
the server call writes into preallocated data, right?

That leads me to my next question: I'm currently working on moving
menus into the server (see
<http://silenceisdefeat.org/~tkho/seas/wine/patches/menu-0622-3/> for
a series of patches that moves most menu data into the server. Most
logic is still on the client, but it's still surprisingly snappy.) If
you look at <http://silenceisdefeat.org/~tkho/seas/wine/patches/menu-0622-3/10-server-mii>,
my problem is that I don't know the size of the data that the server
is going to return and my current hack is to set a hard upper limit.

I can think of two ways to tackle this:

1. Do a server call before hand to request the size of the data to be
returned. This has the overhead of the additional call, but doesn't
increase the complexity of the server itself.

2. Instead of preallocating memory for the variable reply, have the
request mechanism allocate it (like it does on the server end for
variable sized data in the request). This also adds complexity as the
reply would be callee-allocated, caller-freed (or perhaps we could
take advantage of SERVER_END_REQ?). However, it seems kind of natural
to have the request process parallel the reply process.

Is there another alterative? Any comments on which approach is better?

Thomas Kho