[jcifs] Re: Tridge's PIDL compiler and the Samba4 IDLs.

[Michael B Allen]

Eric Glass said:
> Actually, *both* would probably be useful for Jarapac; as Chris noted,
> the Samba folk have done a lot of stuff with PIDL that could be
> leveraged with a backend generating Jarapac stubs.  Plus, it's pretty
> much a given that they will continue prolifically expanding the
> library of PIDL going forward.

I know you're taking the diplomatic position here but to be honest I
actually doubt PIDL could be adjusted to generate good Java stubs. Not
easily. You know there's actually some C code embedded in a few spots? You
could simply ignore that of course but what does it *do*? What you're
really talking about is making PIDL languange agnostic which is a lot
harder if you're starting with something that's somewhat Samba specific.
Not only would you have to adjust the code to be suitable for generating
Java but you would have to also be concerned that it wouldn't break the C
stubs. Then what about the next language?

With idlc you basically get a parse tree that is already language agnostic
[1]. For example NetShareEnum looks like this (this will probably get
mangled by my e-mail but it's supposed to be a table):

Flgs  IdlType           Ptr Name       LangType     NdrTyp NdrSize Attrs
Op  int                   0 NetShareEnumAll int     long   4
Pp    char_t              1 servername short        short  4 string,unique,in
Pp    int                 1 level      NdrLong      long   4 in,out
TPU   NetShareCtr         1 info       NetShareCtr  -      8
switch_is=*level,switch_type=int,in,out
TSM     NetShareInfoCtr0  1 info0      NetShareInfoCtr0 -  8 case=0
Mp        int             0 count      int          long   4
TSM       NetShareInfo0   1 array      NetShareInfo0 -     4 size_is=count
Mp          char_t        1 netname    short        short  4 string
TSM     NetShareInfoCtr1  1 info1      NetShareInfoCtr1 -  8 case=1
Mp        int             0 count      int          long   4
TSM       NetShareInfo1   1 array      NetShareInfo1 -    12 size_is=count
Mp          char_t        1 netname    short        short  4 string
Mp          int           0 type       int          long   4
Mp          char_t        1 remark     short        short  4 string
Pp    unsigned long       0 prefmaxlen int          long   4 in
Pp    unsigned long       1 totalentries NdrLong    long   4 out
Pp    unsigned long       1 resume_handle NdrLong   long   4 in,out

Each row is a 'struct sym' that has a linked list of children of struct
sym. Attributes are in a hashtable. Etc. Flags are:

I - interface
T - typedef'd
C - const
S - struct
P - parameter of operation
E - enum
M - member of a struct or union
U - union
A - anonymous
O - operation
p - primative or pointer to primative (e.g. int, float)

The point is this contains *all* of information contained in the source
IDL. The entire tree is "resolved" down to primative leaf types. If you
have typedefs like:

  typedef [foo] unsigned int uint32_t;
  typedef [bar] uint32_t u4;

and then use this in a struct like:

  typedef struct {
    [zap(3)] u4 val;
  }

The attributes are inherited such that val will have attributes
foo,bar,zap=3. You can generate stubs for any language with ~300 lines of
code [2]. You have to really understand NDR well to write those 300 lines
of code but once you do, that's it, you can generate stubs in that
langauge for any input IDL [3].

Mike

[1] LangType primatives are loaded from a text file called
symtab<lang>.txt (e.g. symtabjava.txt)
[2] emit_stub_java.c is 271 lines anyway
[3] Double subscripted arrays are not supported but it shouldn't be too
difficult to add them. Just wasn't a high priority.