Re: [remote] RFC: Replace qPart with qXfer

[Daniel Jacobowitz <drow@false.org>]

On Thu, Jun 22, 2006 at 12:41:45PM +0400, Vladimir Prus wrote:
> Daniel Jacobowitz wrote:
> 
> > `qXfer:OBJECT:read:ANNEX:OFFSET,LENGTH'
> >      Read uninterpreted bytes from the target's special data area
> >      identified by the keyword OBJECT.  Request LENGTH bytes starting
> >      at OFFSET bytes into the data.  The content and encoding of ANNEX
> >      is specific to the object; it can supply additional details about
> >      what data to access.
> 
> Why do we need OBJECT+ANNEX addressing and opposed to just OBJECT? If
> 'OBJECT' is just a string, can't we push anything in it, without needed
> extra level of addressing?

I inherited this from qPart, but I think it's a good idea - I actually
use it for XML descriptions.

OBJECT is the base of the request.  All "qXfer:OBJECT:read" requests
for a single value of OBJECT are expected to be handled in the same
way.  A stub which supports this OBJECT should return a non-empty
response.  ANNEX is a bit of auxilliary data, in case there's more than
one instance of OBJECT.

For instance:

qXfer:features:read:target.xml:0,100
  Read the overall target description.
qXfer:features:read:CHECKSUMS:0,100
  Read any precomputed SHA-1 checksums for target description files.
qXfer:features:read:foo.xml:0,100
  Read a specific XML file referenced using XInclude.

And then, if one of those is unavailable, it can return either "l" (no
data), or "E00" (annex unknown, or something else wrong with the
packet).

Sure, you could call that "qXfer:features-target.xml:read".  But it's
trickier for the target stub to match it in that case.

-- 
Daniel Jacobowitz
CodeSourcery