perhaps try to make as much of stuff a part of the Perl scripting language. Don't keep /notify command in irssi, but move to a perl script? look at XiRCON: has never crashed on me, and i've used it since the first release... there aren't many commands that actually need to be kept in irssi (and C) even for added speed. Make the interfacing clean, simple, and correct and you probably solve a lot of issues, and make the design cleaner.
And how about using some other language (hint: Ruby)? Perl seems to be a mess to interface with.
--I agree that scripts should hold as much of the features as possible, replybut I also think that irssi should be fully --functioning for most people without external scripting language. --You already note the worst problem, people want to use different scripting languages. People also install irssi in computers --that don't have some specific language installed, Perl is quite safe nowadays since it's been around for ages. I'm IRCing --from a computer that doesn't have Ruby installed, and likely will not be unless I install it into homedir. --Supporting multiple scripting languages is good for giving script coders a choice, but annoying for users who want to use --script done with multiple languages, possibly requiring them to install the language and at the very least use more memory. I -- won't be writing support for more than one language (very likely Perl), but that doesn't mean others can't write it. Irssi's --core doesn't make any assumptions what scripting language you may be using.
I know I'm full quoting, but as this is older mail I wanted to keep the context. I personally think having an internal scripting language is a very BAD idea. If anyone has used MIRC and its insane scripting language I would not like to see yet another client-specific scripting language. Perl is great, but I know it has many detractors. Would it be so difficult to have loadable modules that were interpreters for various scripting languages? Pick one for the base, ie Perl, then produce an API (or even write modules with the project) that support various other major languages. The most annoying thing to me about switching clients is having to learn a new language each time. I would be thrilled (and I'm sure others would be too) if we could script in the language(s) we prefer?
The modules could be loaded at runtime, or statically built in depending on the users needs/wants. Yes you would have scripts floating around in differnet languages, but choices mean your user base would grow. Making the major scripting languages official modules would ensure QA, but you could also make the API easy to access so any language under the sun could theoretically be supported.
Just my $0.02.
Ted
