Patrick-
I think you're missing a couple of points here, and feel free to
disagree with me, I think this is a very important debate that will come up
in every programmer's career and is an important part of the topic of this
list, administering a Win32 network with Perl:
-What tools,modules,and techniques should I use when programming in Perl?
WMI? ADSI? CDO? OLE? Win32::X??
-What techniques do/don't make sense when programming to automate/administer
a Win32 Network?
-When to use a module and when to "roll your own".
-How to make my code maintainable by an untrained Perl programmer? By an
unschooled observer?
-How efficient is efficient enough?
Some of these specifically relate to or are changed if referring to a Win32
Network's administration specifically, and some are issues that every Perl
programmer will face at some point. But to stick to the conversation at
hand, see my comments below:
>> Patrick,
>> I don't see how Moore's law is applicable in this situation. It doesn't
>> matter how fast your computer is if it is trying to process 1000's of
>> requests per second.
>
>We were talking about "Disabling a service"....
Actually I believe you were the one that moved the conversation on to a more
general discussion of WMI vs. third-party modules, but pandora's box has
been opened, so let's look into it.
Your contention that you spend most of your time writing and debugging
scripts and a minimal amount of time actually running them will be contrary
to the experience of many of the people in this list. One of the biggest
reasons, if not THE biggest, for learning Perl for Win32 for an NT
Administrator is to find a way to automate the tasks that he/she has been
doing by hand. Perhaps it has been requested of them that they disable a
service on x number of machines, or perhaps they needed a way to automate
new user account creations to enable them to pass the responsibility on to
someone with less experience with NT Administration. I am not speaking to
your experience, you would know better than I about that. But I will say
that if your aim is the automation of an NT/2000 domain's administration,
then the scales tend to tip a little farther towards the side of faster/more
efficient code.
>> However I don't want to limit my coding to interfaces that I believe
>> will be around in 5 years so that newbies then would be able to
>> understand my programming. That, in my mind, is unreasonable.
>
>Then I respectfully disagree with you.
>
>And it is not about being a "newbie", it is about lacking the time to
>delve into the nuances of every random third-party Perl module.
I feel compelled to mention here that the reason why Win32::Lanman has been
pushed so hard by the Win32 Perl community is the fact that the interface so
closely resembles the APIs while keeping a consistent, easy to use
interface. If you need more information on what a particular Win32::Lanman
function is doing, you can find your information in the Platform SDK from
Microsoft. If Win32::Lanman has one major flaw, it is that, much like the
APIs themselves, the documentation on Win32::Lanman is very large, and it
can be hard to find the name of the function you are looking for because of
its size. But once you've used one function of Win32::Lanman, you can use
another. (for those of you who are not yet playing along at home, get used
to the idea of an Array of Hashes. These show up quite frequently in
Win32::Lanman functions)
>> If you have hired a programmer that can not do enough research to
>> figure out what Win32 API calls are doing then you should fire him
>> right away.
>
>But we are not talking about Win32 API calls. We are not talking
>about writing this stuff in C (although that would be the logical
>consequence of your argument). We are talking about Win32::Lanman.
I think that you have some confusion about the relationship between Perl and
C. Many modules, like Win32::Lanman and Win32::OLE are an interface via a
DLL to C code. AFAIK this is how Win32::Lanman calls the Win32 API, and
this is how you are able to access WMI through Perl via OLE.
>I did not say "never use 3rd party modules". Sometimes they are the
>right choice, especially when they let you write simpler code
>(Net::DNS is perhaps my favorite). But using a 3rd party module which
>provides a *more complex* interface is a bad idea. If you really care
>that much about "performance", then you should not be using Perl in
>the first place.
Again, I think this has a lot to do with your experience, but I would tend
to disagree that Win32::Lanman makes scripts more complex than WMI.
Otherwise I do agree with you on this point. IF a module makes your scripts
more complicated than they have to be, then it is a poorly written module
and should not be used. I disagree on the performance issue. I really
don't think it's too much to ask that Perl scripts be written in an
efficient manner. I do think that some Perl programmers, especially some of
the "old school" Perlers, tend to sacrifice readability for the sake of
efficiency, and this is a mistake in my mind. Anyway, don't be afraid to
continue the debate if you want. I can't promise to agree, but I value your
point of view. Perhaps if you could point out a small example of where WMI
makes it simpler and clearer than Win32::Lanman...
_______________________________________________
Perl-Win32-Admin mailing list
[EMAIL PROTECTED]
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
