Web automation

[Mike Meyer]

qwweeeit at yahoo.it writes:
> answering to Mike Meyer who replied to the following
> assertion on my part:
>  >> but I supposed the everyone knew that web automation
>  >> (and in general  "automation") is only a problem in Linux.
> with...:
>> I don't know it. I don't believe it, either. I automate web tasks on
>> Unix systems (I don't use many Linux systems, but it's the same tool
>>  set) on a regular basis. In fact, I automate *lots* of tasks on Unix
> Perhaps there is a misunderstanding: I intend not the
> script (like bash) automation, but the user emulation on the GUI side,
> which allows automation by programmatically emulating a lot of repetive
> user tasks.

That's a *very* silly way to automate a task. When I'm automating a
task, the *last* thing I want to do is think about selecting menu
entries and pressing buttons on a GUI. I want to think about the
operations on the object in question. A good automation interface will
let me do the latter. A poor one will force me to do the
former. Further, a good automation interface will let my script work
without needing to open a GUI, or even needing the resources required
to open the GUI - unless my script explicitly wants to open a GUI,
anyway.

That's also a very silly way to define automation. Sort of like
defining "transportation" as "a horse and buggy", and then declaring
that people who only have access to Mac trucks or Lear jets have a
"problem with transportation."

> But if the html server only enables the access from a browser, I am
> obliged to cheat and disguise twill as a browser.

So? Most such sites actually enable access from a small set of
browsers. So lots of off-brand browsers have setting to disguise
themselves as other browsers, or even enter an arbitrary string. If
your browser has to do it, why should it matter if your not-a-browser
has to do it?

> By the way you already took part in a discussion on sending keystrokes
> to a GUI application, "fake" flags and low-level programming
> (you proposed python-xlib to avoid indeed low-level programming).

Yes, I'm aware of that. Just because I disagree with your definitions
and think you're doing things the hard way doesn't mean I'm not going
try and help you if I think I can. But when you then make a false
statement - or even one that could be misinterpreted as false -
disparaging solutions I've had excellent success with, I'm going to
point it out.

> But in that I disagree with you. For me it's better to spend my time
> in strenghtening security (firewalls, antivirus etc...) and then choose
> among the various solutions in Windows as far as macro languages are
> concerned (very likely I will choose Autot).

On the whole, I believe that Unix has better macro languages than
Windows. That's because Unix scripting has been around since before
there was MS Windows. Or before MS DOS, for that matter.

> And I can keep on using Python if I want...
>
> The contribution of Paul Boddie is valuable. I too examined DCOP
> and even chose as browser Konqueror, being a KDE application.
> But DCOP doesn't go to such a low level. It is not possible
> to send a simulated keystroke from one KDE application to another.

That you *want* to do those things would seem to be an indication that
you're trying to do the wrong thing. When scripting on Unix, you
usually get to work at a *much* higher level than emulating keystrokes
or mouse clicks. Why would you want to work at that low a level when
high-level alternatives are available? Wanting to do that on Unix
because that's how you'd do it on Windows is sort of like wanting to
process a string character at a time in Python because that's how
you'd do it in C/C++/Java/whatever. You're better off learning to use
the tools on the platform to your advantage than trying to make the
platform be what it isn't.

        <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.