Perl bindings for libsmbclient
dbarth at idealx.com
Wed Oct 13 08:28:39 GMT 2004
Michael : I'm still not sure to see the advantages : you loose type
checking/safety usually enforced by compilers when calling a function
and you need to duplicate (possibly autogenerated code) for decoding the
new DCE_PIPE protocol ? Now, Perl is not really about type safety, so I
loose a point... ;-)
I'm taking a look at Samba4 libraries, with the help of Richard Renard.
I will experiment with Inline::C on a few selected functions I need
(like policy account or workstation lists) and post the list in a few
days. I'll probably try with samba3 and 4 to get an in depth view.
Thanks all for your help in clarifying the subject.
Michael B Allen wrote:
>On Tue, 12 Oct 2004 22:39:47 -0700 (PDT)
>Richard Sharpe <rsharpe at richardsharpe.com> wrote:
>>I think we should be real careful about getting libsmbclient to do too
>>many things. It was intended to implement a POSIX-like interface to CIFS.
>Not sure if you realized my point was consolation for your (actually
>Andrew's) concern regarding the multiplexing of too much functionality
>Again, in more detail -- by exposing a dce pipe through libsmbclient
>you minimize changes to the api and yet open up the potential to build
>a lot on top. For example it could be as simple as:
> pipe = smbc_open("smb://server/IPC$/lsarpc", O_RDWR | O_DCEPIPE);
> LsarQueryInformationPolicy(pipe, handle, POLICY_INFO_ACCOUNT_DOMAIN,
>The stub would handle all marshalling of parameters. Ultimately it would
>just call write and read. Yeah, there would need to be changes internally
>to check for O_DCEPIPE and call a transaction w/ readx and so on but it's
>fairly separable. The idl compiler does the bulk of the work. And voila
>you have a whole range of workstation management functions available
>(in a separate library if it pleases the).
More information about the samba-technical