why I dislike qXfer

[David Taylor <dtaylor@emc.com>]

There are a number of remote protocol packets of the form

    qXfer:object:read:annex:offset,length

For some object or object/annex combinations, this is a reasonable
interface -- for example, when it is referring to data that does not
change (and often it will reasonably fit within a single remote protocol
reply packet).

An example would be qXfer:features.  My expectation is that if we
implement this that it will be compiled in strings.  Unless you connect
to a different target or load new code on the target, it is not going to
change.

A board has a set of features and it doesn't typically change.

But, there are some objects for which it is, in my opinion, a poor
interface.

For concreteness, consider the 'threads' object -- as it is the one I'm
currently wrestling with.

Threads come and go.  And the amount of information I want to return per
currently existing thread means that number of threads * bytes of info
per thread exceeds the maximum packet size.  So, multiple requests have
to be issued to get everything.

The system native format for the information is, of course, not XML.
The per-thread data is variable length (e.g., the name field and, in our
case, the 'extra information').  I want to always return the most
current information.  I want to return information on as many threads as
possible.  And I want to minimize the bookkeeping required.

So, while I can avoid having to store the current position, if I am
going to minimize bookkeeping and return the latest information, I have
to pad each entry to the same size and cannot skip empty (read: dead
thread) entries in the system process table.  If the goal is to speed
things up by, in part, having fewer network round trips, having to pad
is not a win.

With the qT{f,s}{STM,P,V} q{f,s}ThreadInfo (and possibly others)
interfaces, nothing needs to be precomputed, and I either start at the
beginning (f -- first) or where the previous request left off (s --
subsequent).

I have to store, per connection, my location.  But, there is no random
reading.  The next request of that flavor will either start at the
beginning (f) or where the last one left off (s).  Reads are sequential.

With the offset,length interface I don't know that reads will be
sequential so I need to pad and leave gaps.

What do people do?