> Il 14/11/2012 04:50, Wenchao Xia ha scritto:
>> There are some different way to implement, not sure which would be
>> better:
>> 1 keep client as thin as possible, client stores opaque pointer used
>> in server side, for eg, QBlockContext *ctx, client only get a pointer
>> pointing to the address where server stores really the object. This
>> have risk when server/client crash and reconnect.
>> 2 client and server maintains index for QBlockContext and QBlockState.
>> 3 thick client and server layer, expose all structure details in .x
>> file, each API have a correspond rpc call. .x file may be complex.
>> 4 define a custom protocol on XDR, like libvirt, this may need many
>> code in server/client side.
>>
>> also with method 1-3, Consider wrapping following API:
>> int qb_context_new(QBlockContext **context);
>
> What is the return value of qb_context_new? Can it simply return
> QBlockContext*?
>
Yes it can return QBlockContext*. There are more APIs take 3 or 4
parameters, which may be used to retrieve result. In that case I am
afraid a return structure can't be avoided, this may result .x file
looks strange.
>> The parameter context is a pointer that will be modified, it seems
>> sunrpc does not transfer back modified parameter by server to client, so
>> I need to define a structure as
>> struct qb_context_new_ret {
>> int ret;
>> int opaque_len;
>> char *opaque_val;
>> }
>> and use that as rpc call's return structure. In this way each API
>> wrapped need a new defined internal structure make things complicate.
>> so I am wondering if there is a better way to do it.
>
> Surely not all of the APIs return structs this way, however...
>
> Paolo
>
--
Best Regards
Wenchao Xia
