Am Mit, 2002-09-25 um 19.38 schrieb Richard Sharpe:
I do not think that libsmbclient is the right way to do this. I think that the correct way is to make the various Samba client RPC libaries available as separate DSOs so that clients can make dirrect use of what they need. Then the wine group can possibly build a thing DLL wrapper around the underlying RPC libraries.
Licensing is an important issue.
I future Samba RPC libraries come with GPL, they won't be usable for Wine (as you probably know, Wine is LGPL and ReWind X11). I don't want to start a licensing debate here. I expect the Samba team to release their stuff GPL'd in the future, thus I accept is as a fact that Wine cannot be linked to Samba libraries, present or future.
For that reason I find the winbind concept of socket communication attractive. To my understanding this would not raise license issues. We are not currently worried about performance, we just need access to a few RPC calls.
To initiate this process we'd "only" need a standardized protocol for the socket communication. Andrew said that doesn't exist and won't with regard to winbind. I'd like to focus the discussion in this direction.
- is the winbind team willing to standardize the protocol, or at least ensure backward compatibility in future versions? - is the winbind team willing to add more RPC calls to the interface?
If not, Wine might do best by creating a "winebind" that meets these requirements. That might be the best way after all, because incorporating the functionality needed by Windows clients into winbind would make no sense in environments where Wine is not running, just increase winbind's size unnecessarily.
"winebind" would be linked against Samba libraries, and therefore be GPL from the start.
Martin