> Martin,
>
> Neat ZAAP, and that's before even having a chance to actually play with
> it.

Thanks!

> I believe that such potential conflict is what this (from zaap.txt)...
>
> || In order to support a set of commands unique to a particular Assistant
> || Application, developers should register with Zedtek their preferred 'Client
> || Identifier' (passed in the entryline field below).

I knew I'd read something like that! Couldn't remember where though, and apparently read right over it when reviewing zaap.txt...

It's always felt a bit kludgy to me, though, to require users to prepend a ZAAP identifier. I've no better solution, though (not without major redesign of the ZAAP architecture, that is) :-P.

But as usual when I'm still in doubt, I left that issue for a later time and version. (Very bad habit, I know).

> ...was meant to address. Having multiple ZAAPs compete to process and
> write back return codes to the same Y commands in the same zbar.dat file
> is a scenario neither workable nor desirable.

In truth it hasn't been much of a problem so far (but perhaps that's more due to the scarcity of command-supporting ZAAPs, or rather, the little use I make of them).

> I am not necessarily suggesting that every ZAAP must formally register
> its own prefix, but it might be safer to avoid too common command names
> like "match".

Agreed. I was thinking of registering s (for scripting), and provide a mechanism for scripts to register their own commands with the script host.

Like I said, this version is still a bit rough around the edges... I should've called it v0.1, instead of v1.0. :-)