Hi folks,
now that SambaXP is officialy over, the samba team a couple of other people have retreated to a smaller room to discuss other things.
Steve French had a talk about using CIFS on linux as a replacement to NFS which seems to be pretty cool. A couple of other talks were given, too, but if you're really interested, have a look at the schedule[1].
What was more interesting was that after the talks there was a panel discussion where the samba team expressed interest in continuing cooperation with Wine as discussed on last year's wineconf.
Steve asked how exactly we wanted the named pipes exposed and if we could write up some testcases for that stuff. I think if anybody is interested in working on that is to email Steve directly.
I got some more work on GENSEC done, but in order to really link this together, some more work is needed. I still have things blowing up on me when trying to use it for client-side sspi.
Well, that's it for today, Kai
[1] http://www.sambaxp.org/index.php?id=25
Kai Blin wrote:
Hi folks,
now that SambaXP is officialy over, the samba team a couple of other people have retreated to a smaller room to discuss other things.
Steve French had a talk about using CIFS on linux as a replacement to NFS which seems to be pretty cool. A couple of other talks were given, too, but if you're really interested, have a look at the schedule[1].
What was more interesting was that after the talks there was a panel discussion where the samba team expressed interest in continuing cooperation with Wine as discussed on last year's wineconf.
Steve asked how exactly we wanted the named pipes exposed and if we could write up some testcases for that stuff. I think if anybody is interested in working on that is to email Steve directly.
There are 3 things that Samba could do to help Wine: 1. Expose SMB operations in a library, including named pipe operations. The library functions exposed would ideally be similar to the Win32 functions, i.e. ConnectNamedPipe, CreateFile, ReadFile, WriteFile, CloseHandle, etc. 2. Expose an API that would allow Wine (and other applications) to register an endpoint in the Samba endpoint mapper. This API would be along the lines of samba_epm_registerep(UUID *object_uuid, char *protocol, char *endpoint), and a corresponding unregister function. 3. Create a server that would contain interfaces necessary for DCOM (specified in the draft RFC), plus some other interfaces, like the running object table and ways of registering objects to allow them to be activated. Ideally, these would be compatible with Windows to allow ole32 from NT to be used, but that would require reverse engineering some of the interfaces.
* Robert Shearman rob@codeweavers.com [27/04/06, 19:08:49]:
There are 3 things that Samba could do to help Wine:
- Expose SMB operations in a library, including named pipe operations.
The library functions exposed would ideally be similar to the Win32 functions, i.e. ConnectNamedPipe, CreateFile, ReadFile, WriteFile, CloseHandle, etc.
I'm pretty sure the Samba team isn't too happy to open too much of the Samba code to LGPL. We might need to figure out a way to interact wit this stuff without linking to it.
- Expose an API that would allow Wine (and other applications) to
register an endpoint in the Samba endpoint mapper. This API would be along the lines of samba_epm_registerep(UUID *object_uuid, char *protocol, char *endpoint), and a corresponding unregister function.
I guess the same licensing problems arise here. Plus, I have no clue what that endpoint mapper is. I guess the correct place to ask about that stuff is #samba-technical on freenode or the samba-technical mailing list.
Cheers, Kai