[JDEV] Client scriping language

[Patrick McCuller]

> The problem with deciding a scriping language for a general purpose
> application is one needs to know, ahead of time, what type of portability
> issues will arise and what the language is actually needed for.
> The question
> that kicked the whole debate off was "what scripting language
> will we use?"
> (not verbatim) No limit, no reference, and no use was given. In a response
> post, I suggested that we link the scripting language into the client and
> have it control the UI. Further posts have hinted towards the language
> portable and transported between the clients themselves. It is these two
> purposes that I have in mind.
>

	Actually, as the person who in fact asked the question, I asked what
language you - you the reader - would like to use to customize a Jabber
client. A specific client, as my email made clear.  That's a much narrower
topic than you imply. I had already integrated two scripting languages with
my client, JPython and Beanshell. They were easy enough to do, but I don't
care for Python myself and Beanshell isn't widely adopted to my knowledge. I
wanted to know what the people most likely to use the scripting feature -
the developers on this list - would want to use.

	I really didn't mean for it to get out of hand. I felt sort of bad about
it, watching the replies spin out into completely unrelated realms, most of
them missing entirely the point of my question. I did get some useful
information out of it: everyone wants to use their own favorite scripting
language, and there's not much consensus except a general leaning towards
javascript, jpython, and perl. Honestly, I have no intention of integrating
perl with my Jabber client, but someone else might, and I am leaving open
the door for that as well: script engines are dynamically loaded, and a
programmer would only have to implement a very small interface adapter in
java. Five easy methods.

	That the thread spun out so far made me regret asking. That's why I sent
the subsequent followup: some enterprising person please create a client UI
list and migrate the discussion there. It is a rich topic! That's clear.
Everyone has ideas about it, and everyone should have the chance to talk
about them.

	Let me address a couple things regarding client features: first, I did not,
and do not, suggest creating a language of any kind. There are plenty of
people who love to create languages for everything. Let them. Let them
create a jabberscript if they like. But I certainly never suggested it, and
I do suggest that it would be foolishly wasted time. There are plenty of
languages in the world, none of them perfect, and whatever ad hoc script we
brewed up, it wouldn't be among the great, or even good.

	Nor do I suggest standardizing on a scripting language for Jabber clients
or what have you. It seems to me that it doesn't matter. Buy hey, if you
must, go ahead.

	Also, I think it would be helpful if those on the list interested in
contributing to Jabber client feature discussions internalized the idea that
there will not be a one standard Jabber client. Let me repeat that: there
will not be a one standard Jabber client. Every list subscriber, and in fact
everyone, is perfectly welcome to create whatever sort of client they
desire. No client is going to make everyone happy, and I suggest that any
given client will actually make most people mad.

	I'm pretty sure that Jeremie will back up that the Jabber protocol,
extended to support MIME, S/MIME, RDF, Reverse Polish, or anything else, was
designed from the start to support very simple clients. A good example of
this principle is that clients aren't even required to understand errors:
they're just special case messages, which can be ignored and shown to the
user. Simple, basic clients will always be supported by Jabber. Jeremie is
unlikely to change that. Obnoxious clients will be shunned; the right way to
make an extension happen in a client will be clear.

	Now, that doesn't mean that Jabber clients can't support whatever you like.
Most of them probably will. Some people will want, and create, a client with
zero whistles and bells that runs on a wristwatch in 2K of RAM. Others will
undoubtably want to play Quake III in a chat window while the client
automatically translates and voice synthesizes Mandarin Chinese. And why
not?  Why am I laboring this point? Because it makes whining about the
inclusion of whatever feature annoys you pointless. Pick a client that
doesn't use it. Clients will not be forced to do things they don't want to
do. Some clients may not act much like a typical GUI client at all: I have a
java app that just sits there on the server, responding to incoming messages
with a fortune.


This is a Blue Sky observation, not Flame Bait:


	Jabber isn't ICQ. Complaining about and comparing features to ICQ or AIM or
Yahoo Pager or whatever you like is healthy and good. Feedback to the
authors is always great. But Jabber isn't like ICQ or AIM or Yahoo or MSN
Messenger, for this one reason beside many others: Jabber is not a marketing
tool. It is the dream of a communications channel that anyone can use. No,
it won't affect the survival of the species. But it might make your day, and
that's better than most software can manage.


[snip]


> It seems I'm forced to choose between Python and ECMAScript only because
> they are the lesser of the many daemons. Unfortunatly, I can't. I leave it
> up to the implementor of the code to, in the end, make the choice.
>

	I just wanted to note that in the body of the email with my question, I do
address this with regard to the client I'm putting together. Quote from the
original email follows. Any application with a strong design should be able
to support multiple scripting languages.


	"The intention is for third parties to build their own script interpreter
adapter."


Patrick