[jcifs] RPC Stub Format Changes

[Eric Glass]

> 
> But we can use these objects throughout the code. For example instead of:
> 
>    PresentationSyntax syntax = getSyntax();
>    uuid = syntax.getUuid();
>    ndr.writeElement((uuid != null) ? uuid : new UUID(UUID.NIL_UUID));
>    uuid = getActivity();
>    ndr.writeElement((uuid != null) ? uuid : new UUID(UUID.NIL_UUID));
> 
> We could generate p_syntax_id_t and do:
> 
>    rpc.p_syntax_id_t syntax = getSyntax();
>    uuid = syntax.if_uuid != null ? syntax.if_uuid : NIL_UUID;
>    uuid.encode(ndr, ndr.getBuffer());
>    uuid = getActivity();
>    uuid = uuid != null ? uuid : NIL_UUID;
>    uuid.encode(ndr, ndr.getBuffer());
> 

Yes; most of the classes in rpc.core were objects that are used by the
RPC subsystem directly, but should be generated from IDL (UUID, etc.).
 If feasible, that would be the ideal approach.

Note that that implies a dependency on the stubs in some of the core
classes (i.e., the bind PDU "knows" what a presentation context is; so
to compile it you'd have to generate the stub ahead of time).  It
would probably be prudent to define an IDL->Jarapac binding "standard"
to define what Java artifacts would be generated for a given IDL. 
This would have a couple of benefits:

1) Interoperability; Chris's PIDL backend could generate stubs that
could coexist with IDLC stubs.  You could use either tool to generate
the stubs, and compile the core (or anything else) against either
tool's output.

2) Consistency.  Regardless of differences in tool versions, etc., the
user knows that compiling "rpc.idl" will give them a given set of
output files; so they don't have to worry about whether their code
will be broken by future changes.

I think the standard will probably be "whatever we define here and
ends up working well". ;)  Once things have worked out and are running
nicely, I'd just like to use that as the basis for a documented
binding standard.


Eric