Timothe, Reini Thanks both for your feedback.
On the topic of top-level namespace: It's not a biggie, although Win32:: may look a bit misleading at times, I accept that it is the defacto 'standard' and can certainly fit in underneath. And yes, 'Windows' is maybe too generic anyways.
[Timothe] Whether I should shoot for a distro that is an abstraction of SSO in general is for me at this point shooting way over the top. I have little experience with Krb and others and so have no idea what other abstractions would be useful in coming up with a generic framework that would allow nice pluggables. So I would at this point try to stick with the Win32 backend and if someone ever is capable of coming up with the definitive SSO framework I hope it would be reusable as-is, or at least provide lots of code to enable things to fit in.
I can understand your words that Perl is about portability. But so is Java, to a much greater extent, and the great thing about Perl in comparison is that Perl does allow you to much easier drop down to direct and non-portable OS access if you need to. And as you also mention, sometimes you really do; there are API's/mechanisms that simply does not exist or even make sense elsewhere. Being able to access them easily (without having to drop down to C) is a big win. The example of MessageBox is just an example, obviously silly in most ways, it's just a convenient API to try things out with when messing with Win32::API and similar. Then again, if all I ever need is a message box (in an already Win32 specific module), why involve Tk at all?
[Reini] After digging around in Win32::IntAuth I didn't feel it suited the type of use I needed it for, lacked abstractions for certain things, and mapping my ideas on top of it I would effectively end up with a almost complete rewrite. And remember, it does two things: it both sets up the the actual interface to Secur32.dll and then uses it. I would prefer to split this into two parts: the raw DLL interface in one distro (so the interface can be reused if needed and as a bonus also be used for any other conceivable DLL in a manner that arises the abstraction beyond Win32::API), and the actual wrapping of the underlying concept of a SecurityContext is in a separate distro. So it's a two-step process and at this point I'm considering the first one. But true: if I have the first part of wrapping raw DLL's I might try to produce a rewrite of W::I utilizing that...hmm...
Your comments about XS however doesn't make total sense to me. Maybe I'm unclear, but I think there's a great point in being able to avoid C code if possible. Then we don't need a compiler at all. If you are suggesting that for every possible DLL function you always would need to write a lowlevel C part, then that would just make things harder or even impossible for those without C knowledge. In contrast, declaring a function prototype in text you get almost directly from MSDN and pop it into Win32::API (and with some extra tracking allow handling out OUT params, automatically importing function names etc etc) seems simpler. Yes, this is runtime rather than compiletime, but generally speaking, the Win API's I'm seeing are quite stable. I'm sure there are instances where Win32::API might not be enough and/or dynamic, runtime linking is inappropriate and then we can drop down another level, but so far that mechanism works good enough for my needs in my opinion.
ken1
