On Dec 16, 2007 4:08 PM, Kai Blin kai.blin@gmail.com wrote:
On Sunday 16 December 2007 22:47:23 James Hawkins wrote:
ws2_32 or wsock32, or both, depending on the existing bugs.
Given that wsock32 forwards over 90% of the calls to ws2_32, let's go for that one then.
Coming to think about that, if we're fine to add more categories for things like secur32.dll, how about splitting up those by debug channel? E.g. my ntlm provider has an "ntlm" debug channel, the kerberos provider that I keep starting and restarting in some branches on my box always uses "kerberos", and Juan might want to use schannel as debug channel.
I have to voice my disagreement on this one. per-debug channel is too fine-grained, and that's a road we don't want to go down. Think of it like this: the components are not meant to help the users in any way, only the developers.
But I as a part-time developer can't keep track of all the areas in Wine. I don't know anything about.. say GUI.. or actually anything that's not secur32 or maybe winsock. Where's the advantage of me refiling a bug someone filed as.. say "ws2_32" to "default" again because I don't know what gui component is responsible as opposed to me refiling it as wine-gui (see bug 9771 as a specific example that just came up).
You refile it as misc/default so another developer who is more familiar with the correct component can set the right component. We're getting rid of wine-gui because wine-gui doesn't mean anything...the bug description alone is enough to know that it's a gui bug.
As a developer, will the different provider components (ntlm, kerberos, et.al.) help you any? You'll have to read the logs anyway.
Well, maybe. Once schannel is implemented, I probably won't look at those because I don't know about schannel. I don't get your point about having to read logs, because I think that is needed for all but the most obviously invalid bugs.
You said an advanced user could read the logs and set the provider component based on the fixme's in the logs, and I'm saying that you'll have to read the logs anyway, so the one advantage of that method is taken away.
schannel, on the other hand, is a module in the wine tree, so that would be a useful component.
Nope. It forwards to secur32.dll, apart from two calls. I'm kind of certain we're just arguing about what color the bikeshed should be painted in, but either we just lump all sspi errors into one category, or we have one per logical module.
I have no idea about secur32, schannel, etc. If schannel just forwards to secur32, then there's no need for an schannel component, and any bugs of that nature should be marked as secur32. That still doesn't mean we need an sspi component.
So I guess the real question is how much diversity we want and need.
If most of the functionality is in secur32, where's the need for sspi, and if there's more functionality in other modules besides secur32, then there should be a component for each module that has a reported bug. Like I said before, I don't mind an sspi keyword.