--- Mike Hearn m.hearn@signal.QinetiQ.com wrote:
It'd be a tragedy to reimplement all that of that code because of GPL vs LGPL concerns.
I agree. Andrew Bartlett did too in an email he sent me. The reason I've backed off from this is that it's hard to do correctly, and anything less than completely correct isn't going to be accepted by A.J. Ideal for us would be a file descriptor that we can do atomic operations on; that'd be duplicable like the rest of our handles. Not sure how we'd get that from smbd (see below for a different idea), and Samba3's public API is too high-level to be of much use to Wine. (Samba4 might be better.)
Given the ports problem, maybe the solution is just to have smbd expose an interface that lets you manage named pipe connections through it. Not thought about this problem much though.
The ports issue prevents us from receiving connections, i.e. acting as a DCOM server. This is probably less important than being able to act as a client, at least for a while.
I asked Steve French (Linux CIFS module) whether he'd consider exposing named pipes in the Linux filesystem. He said he would, then asked me whether I'd given any thought to naming convention. I hadn't and I haven't had as much time to experiment with this of late, so I haven't responded. This method would allow us to act as a CIFS (TCP port 445) client. Acting as an SMB (TCP port 139) client isn't handled by the CIFS module, it's done by the SMBFS module. Not sure what Steve's plans are here.
Anyway, any of you guys interested in seeing RPC work under Wine (Greg, you still lurking around here?) might want to play around with this if you have time. I might myself once I land somewhere for a while, but no promises.
--Juan
__________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail