[JDEV] Jabber - Scripting Language

Thu Jun 7 17:46:31 CDT 2001

Here are the useful scenarios I've imagined off the top of my head (let's
ignore the security implications for now...:-)  For sake of discussion, when
I say Message Type, I'm referring to a generic type of message, not the
actual Message Type in Jabber's XML ... :

Server Side Scripting:

1. Rules Processing - Rules may need to be executed when a client is
offline.

Say a message of type text arrives on the jabber server for
user at jabber.com/resource .  Before delivering the message to client or
client queue, the server checks for any scripts to be executed.  Scripts to
be executed could be based on message type (text, file transfer, voice,
etc.), from user, to user (if there's a difference in a user vs. group
address), date/time, etc.  These server scripts might then take one or more
of the following actions:
a. redirect the message to another (one or more) jabber address (a different
user, a different resource on the same user, etc.) or even out a transport
(transports might exist for things other than IMs, say, for example, a
controller for a robotic arm or camera :-).
b. Forward the message to another (one or more) jabber address (different
than redirecting)
c. Auto-delete the message
d. Update a database based on the content of the message
e. Log information
f. (egads) Execute an aribtrary cgi like process on the server
g. Execute another script

Client Scripting

1. Rules Processing - Rules Processing on a client requires the client to be
running ... this is not useful for offline scenarios.  Otherwise, see
Scenario above
2. Client Message Extensions - Given Client X supporting Text, File Transfer
and Chat messages, I should be able to extend that client to accept any
future message type, say Voice, through a Client Message Extension
registered with the client.  When the client receives a message type which
it doesn't recognize, it searches the Client Message Extension registry for
that message type.  If it's found, it runs the extension and passes the
message to it for processing.  Additionally, the client would call this
extension for any action the user wishes to take on the item. Once the
extension has the message and an action, it can then display a form (if the
user has indicated the "open" action.)  Extensions should be able to be
written in any language also.
3.  General Client Scripting - Most applications (such as code editors)
provide a generic set of scripting support allowing scripted applets to add
additional User Interface and execute client actions.  This facilitates the
integration of third-party products.  An example of this is the ICQ
extension in Outlook or Add-Ins in Visual Studio.  This may also allow a
scripted applet to add any arbitrary menu item or toolbar button to take
some scripted action.  This provides enhanced functionality and flexible for
clients.

IMHO, these features are incredibly important.

I would hazard to guess that whichever client comes out with these types of
extensions first would "win the game."  I think many people will still want
to write their own clients, but I think far fewer just want to focus on
their business logic, and not the underlying client technology.

For example, I am working on a voice client (cb style.)  To do so, I have to
run it as a separate application from WinJab (I don't use Delphi.)  This
means I have to provide all the features of WinJab to get users to use my
client, or force them to run 2 clients completely independent of each other
(and on different jabber address by means of a different resource.)

It would have been far quicker (and it would be out there already) if I
could have just written a small DLL to handle a message of type VOICE (or
MYVOICE if we didn't have a central message type.  Then I could have
instructed my clients to download and install WinJab, then my Voice
Extension.

And Peter would much the happier with all those extra tech-support emails!
<evil grin>

Thanks,
MikeE

-----Original Message-----
From: stpeter [mailto:stpeter at jabber.org]
Sent: Thursday, June 07, 2001 4:54 PM
To: jdev at jabber.org
Subject: Re: [JDEV] Jabber - Scripting Language

I find the idea of scripting within Jabber to be intriguing, but I'm not
clear on what people want to do with this. Can you provide some scenarios?

On Thu, 7 Jun 2001, John Alex Hebert wrote:

> On Thu, Jun 07, 2001 at 09:36:38PM +0100, Al Sutton wrote:
> > My watcher system is built on top of my jabber engine in a way that all
of
> > the watcher logic is separate from the code. Building upon it I could
make
> > an engine that could act like the rules system in Outlook Express if
people
> > feel it would be useful.
> ...
> > P.S. It would be written in Java.
> > ----- Original Message -----
> > From: "Todd Bradley" <TBradley at jabber.com>
> > To: <jdev at jabber.org>
> > Sent: Thursday, June 07, 2001 8:26 PM
> > Subject: RE: [JDEV] Jabber - Scripting Language
> > > > Has there ever been any discussion of a client side scripting
> > > > language for
> > > > Jabber?  I'm thinking of something along the lines of mIRC's
scripting
> > > > language for the IRC protocol.
> > > That was the source of my original interest in the
> > > Tcl client (zABBER).  My goal was to have a client
> > > that had a scripting language interpreter so you
> > > could write scripts to do special handling of events.
> > > But, alas, it's not that advanced.
> > > To answer your question, I don't think there's been
> > > serious discussion in the past year about a single
> > > "official" Jabber client scripting language.  It
> > > would probably be impossible to get everyone to
> > > agree what that language should be.
>
> Agreed.
> As much as I would like to see Python used more in the Jabber effort, I
think
> making or choosing any particular language to be the "official" scripting
> language would detract from the whole Jabber effort. I say we would
benefit
> more from having a few different working prototypes of scriptable jabber
> clients first before we begin to mention the word "official".
>
> We would miss out on some potential good ideas, like Al's above, by
> influencing developers to use an
> "official" scripting language (Javascript anyone?) rather than approaching
> the problem with a beginner's mind.
>
> Code first, then bureaucracy. :)
>
> --
> John Hebert
> System Engineer
> http://www.vedalabs.com - changing your state of mind through sound
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
>

_______________________________________________
jdev mailing list
jdev at jabber.org
http://mailman.jabber.org/listinfo/jdev