The client may issue a get_vector command and expects to receive back a list of polygons and text that he can display within his application. It will be the client's responsibility to best determine how to render the primitives and text.

Here are my suggestions (remember I am not a programmer ....)

reference location - primitives are returned using the database coordinates that they would have in the GDSII database. (in user units or in nanometers?)

types of primitives - paths, boundaries and text. A possible special case is a rectangle (Eric, do you have a efficient Manhattan rectangle entity?) because the GDSII representation of a rectangle is needlessly inefficient and many GDSII files consist solely of Manhattan rectangles.

properties - each primitive will include a layer tag (two bytes) and a datatype tag (two bytes).

text primitive - text can be very important as it is often used to identify structures or nets. A text primitve which is generated from GDSII should include the same set of properties as it does in GDSII:

height (magnitude)
reference location (1/9 possibilities)
string
rotation angle
mirror flag
layer (datatype?)

Header - not only should the header include some magic number so that the client can recognize the data as primitives, it should include information about "size" of the stream and possibly the number of primitives.