> I thought about that, but then it means the application data can only be > transmitted in the new Empty message, not with a RecordBatch.
Agreed! Both are useful. > I hope we can find a way of transporting statistics together with the > corresponding RecordBatch message, as opposed to a separate message in > the IPC stream. That's a great point...I was mostly trying to validate Rusty's point that I can see how that type of extra data might well be a table. On Thu, Feb 5, 2026 at 2:46 AM Antoine Pitrou <[email protected]> wrote: > > Le 05/02/2026 à 04:44, Dewey Dunnington a écrit : > >> a new application_data field in the Message table to pass arbitrary > >> opaque data with any kind of message > > > > I believe this could be done with the Empty message by putting the bytes > in > > the body instead of in the header. Probably the only place this > > functionally makes a difference would be dissociated IPC where the body > is > > transported separately. Perhaps both are useful. > > I thought about that, but then it means the application data can only be > transmitted in the new Empty message, not with a RecordBatch. > > That's not necessarily a problem, just a limitation to think about. > > >> It could be interesting to support multiplexing multiple IPC streams > over > > the same socket > > > > I agree that there are some applications of the Empty where it would be > > tempting to have the payload of the Empty be serialized IPC (e.g., if > used > > for statistics and the statistics are encoded in the lovely Arrow spec we > > have for that). Perhaps with Empty one could prototype that. > > I hope we can find a way of transporting statistics together with the > corresponding RecordBatch message, as opposed to a separate message in > the IPC stream. > > Regards > > Antoine. > >
