Perl bindings for libsmbclient

[David Barth]

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

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
>thorugh libsmbclient.
>
>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,
>&info);
>
>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).
>
>Mike
>
>  
>