Perl bindings for libsmbclient

[Michael B Allen]

On Wed, 13 Oct 2004 11:14:23 -0700 (PDT)
Juan Lang <juan_lang at yahoo.com> wrote:

> Agreed.  Again, assuming Wine continues to use its own
> RPC code, the easiest thing would be to be able to use
> a file descriptor to read from/write to as our RPC
> transport.  A named pipe transport would be especially
> useful, since that seems to be one of the more common
> usages.  A TCP transport would be my vote for
> runner-up.

This is pretty much what I suggested before. If you expose a DCE pipe
the interface between the RPC world and the client is fairly simple. You
just have to be able to specify an opcode, write a buffer, and read the
response buffer. Then you can use an idl compiler to generate marshalling
routines on top and leave the client code alone.

Incedentally I don't know if you work on wine but the wine folks might
be interested in an MS IDL compiler I recently wrote being that it's
midl compatible [1]. I could write a skeleton emitter for generating C
client stubs (currently we do just Java) if it's something people are
interested in. Writting an emitter for generating other things like
headers or documentation is quite easy too. Basically you get a tree of
objects that contain *all* of the information in the idl. You traverse
the tree and printf what you want in the output. It's here:

  http://jcifs.samba.org/src/idlc-0.4.0.tar.gz

The DCE pipe approach is also nice because you can use idlc or PIDL or
hand written routines or whatever.

Finally, I think it's worth mentioning that by DCE pipe I mean a
named pipe that will do the DCE bind and use additional ReadAndXs as
necessary. Just exposing a straight named pipe doesn't quite cut it.

Mike

[1] actually a subset of midl functionality meaning we don't support
every attribute, dcom, etc but what is supported is totally capatible
(e.g. embedded conformant arrays that prefix the struct with a long)

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