round 1: ndr on top of trans2

[Amin Azez]

* Stefan (metze) Metzmacher wrote, On 18/01/08 12:03:
> Amin Azez schrieb:
>   
>> It'll be a new day before I can test this, but taken that it works (or
>> can be made to) is their anything architecturally offensive in it?
>> Have I missed any useful use of params (which I ignore)?
>>  
>> smbcli_ndr_request_trans2_send() sends (or at least constructs right
>> now) a trans2 smbcli_request based on an NDR representation produced by
>> gen_ndr generated code, and packed directly onto the smbcli_request, to
>> save tallocs and memcpy.
>>     
>
> I think using ndr makes no sense here at all.
>
> It would really be help full to chat with you on
> the irc channel (#samba-technical on freenode.net)
> next week. I'm usually online from 8:00 to 16:00
>   
Your Date: header suggests that this would be at least vaguely european
time. I'll hope to catch you then.
> The more important thing is: what are the logical
> operation and their input and output parameters.
> Thinking about the transport layer should be a second
> step.
>   
I need to add extra facilities to read operations to permit compression
of responses, and the read request/response to make use of file deltas
from a cache system; and similarly for write operations; or: I need
read/write variants that have different and more arguments in both
directions.

And then I need further operations for general cache-engine synchronization.

Transport progression (!) has gone like this:

1. abusing existing well defined operations (when the peer has the right
capability set)
2. defining my own operations (to work similar to SMBREADX, but taking
unused op-codes)
3. being told to use a trans2 subcode,
4. to being told to use DCERPC (before I had time to do 3)
5. being told DCERPC is not good for async (which puts me back to trans2)

I really want a transport that preserves tid/mid/pid contexts anyway, so
it ought to be (2) or (3).

Why am I using NDR? Because looking, and samba notes, suggest that it
will save packing and unpacking my data by hand, but use of NDR seems to
be the mildest of concerns.

I should probably try to avoid optimizing NDR over trans2 in the short
term and just close my eyes to the copying of blobs.

I'll try and catch you on IRC next week.

Sam