ARROW-11911: [FOLLOWUP] Clarify relationship between Arrow and Protobuf in Flight
How the `FlightData` handling works in Flight implementations is a bit outside the scope of a FAQ document like this, but this at least clarifies that Flight does not serialize the data itself (only a binary blob is passed by Flight) using Protobuf.
Closes #102 from wesm/ARROW-11911-followup and squashes the following commits:
f88d43614 <Wes McKinney> Clarify protobuf relationship in Arrow Flight
Authored-by: Wes McKinney <wesm@apache.org>
Signed-off-by: Antoine Pitrou <antoine@python.org>
diff --git a/faq.md b/faq.md
index 146984b..946c221 100644
--- a/faq.md
+++ b/faq.md
@@ -229,12 +229,13 @@
been deserialized by protoc generated Java code. You would need to marshal
the data from one language to the other.
-Arrow avoids this but it comes at the cost of increased space. Protobuf can
-be a better choice for serializing certain kinds of data on the wire (like
-individual records or sparse data with many optional fields). Just like
-Parquet this means that Arrow and Protobuf complement each other well. For
-example, Arrow Flight uses gRPC and Protobuf to transmit data which is then
-deserialized into Arrow format for processing.
+Arrow avoids this but it comes at the cost of increased space.
+Protobuf can be a better choice for serializing certain kinds of data
+on the wire (like individual records or sparse data with many optional
+fields). Just like Parquet this means that Arrow and Protobuf
+complement each other well. For example, Arrow Flight uses gRPC and
+Protobuf to serialize its commands, while data is serialized using the
+binary Arrow IPC protocol.
#### **How does Arrow relate to Flatbuffers?**
