[jcifs] RPC Stub Format Changes

[Michael B Allen]

On Mon, 16 Aug 2004 04:32:08 -0400
Eric Glass <eric.glass at gmail.com> wrote:

> > 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. 

Well generating that code from IDL would do that alright. And I snarfed that
IDL right out of the DCE spec so thats pretty standard.

> 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.

But another compiler might create separate files for every class within the
interface or upcase the first letter of each class name for example. So to
ensure interoperability one would have to also agree on the Java interface
as well. I suppose that's what you mean.

> 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 in practice the code in question will never change so we generate it
once and forget about it. We don't even have to make it part of the build
process. We know the encoding of PDUs and structures never changes so ....

I'll concentrate on making the compiler work well. It will be a nice tool to
assist with routine NDR marshalling code.

Mike

-- 
Greedo shoots first? Not in my Star Wars.