Re: Naming module (Windows specific)

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