[JDEV] Jabber Scripting Language Proposal

Emswiler, Mike MEmswiler at protrader.com
Thu Jun 7 22:54:31 CDT 2001 

I would like to propose a simple implementation for Jabber Scripting that is
useable on both servers and clients.

It's not as fancy as, say COM, but it's quick, easy, flexible and
cross-platform - what more could a programmer ask for?

For the sake of the discussion, I'll use the following terminology

Script Host	-	Jabber Server or Jabber Client
Script Client	-	Extension to be executed

I propose that all communications be based around XML, of course.  The
Script Host should implement the following protocols:

1. CGI SCRIPT		The Host spawns a cgi application with redirected
Standard In and Standard Out.  Data is passed to the cgi app in XML format
over standard in, and actions and data are received back from the app in XML
format on standard out.  This is a rip-off of Web-Based CGI but works well
in this situation for either the Jabber Server or the Jabber Client.
2. LRWP SCRIPT		The Host opens and listens for LRWP applications
(Long Running Web Applications) - also a rip-off from Web Servers.  The Host
would open a TCP-IP port (for security reasons probably restricted to the
localhost only) and wait for an LRWP app to connect.  Using a Select() like
functionality, this Host would allow multiple simultaneous LRWP Applications
to connect.  XML Data would be sent to each application as needed through
TCP/IP, as well as receiving returned XML Data from the LRWP over the same
socket.
3. EXEFILE SCRIPT	This is the cheesiest and lowest common denominator
implementation and should probably be ignored altogether (however, in some
environments, it might be the only way.)  The Script Host writes the XML
Data to a disk file, say input.XML in a newly created temporary directory
for this execution request and passes the path/filename via command line
argument to any arbitrary EXE.  The EXE must return TRUE or FALSE exit code
to tell the Script Host if any XML Data results are to be returned and
processed by the Script Host.  If TRUE, the Script Host opens and reads
output.xml in the same directory where it put input.xml - if FALSE, there is
no input to read and the Script Host is done.  (egads, the server-side
scalability on this would be horrible...)

Personally, of the 3 choices, I prefer the LRWP option ... a small
cross-platform LRWP connection library could be assembled to assist others
with the TCP/IP underpinnings and completely abstract them from it, save a
few calls like LRWPConnect(), LRWPRead(), LRWPSend(), and LRWPDisconnect().
As an ANSI C library, this could be used by most any language.

All three of these solutions are completely cross-platform and server
different needs.  Some languages/environments can't generate EXEs.  Some
can't redirect standard in/out, and some don't have sockets support.
Supporting all 3 seems to cover all our bases.

Anything written as a Script Client using one of these protocols would be
guaranteed to work, cross-platform, with any Script Host it was targeted for
(Jabber Server or Jabber Client.)  That is, any Script Client for a Jabber
Server will work with any Jabber Server.  Any Script Client for a Jabber
Client will work with any Jabber Client.  Script Clients for Jabber Client
will not work with Jabber Server (obviously, servers and clients will have
different actions/commands available.)

What would need to be finalized upon acceptance of any part, or all, of this
proposal is the XML format to the script client and back from the script
client.  For example, a Jabber Client may wish to pass a "Message Received"
Notification to the Script Client, this would need to be in an XML format,
perhaps followed by the XML of the actual message received.  Further, the
Script Client, may wish to return a command to the Jabber Client in the form
of "Auto Reply Message" (this command would have to be in XML format too)
followed by the XML Jabber Message to actually Reply with.

So, for each Script Host (Server and Client) we'd need a separate list of
available Actions/Commands/Queries and accompanying DTDs and protocols.

How does this sound to anyone?

Thoughts, criticisms, large signs bearing vulgar messages?  Should I break
out my anti-stone armor?

Thanks,
MikeE

-----Original Message-----
From: Ryszard Sommefeldt [mailto:ryszards at xnl-interactive.com]
Sent: Thursday, June 07, 2001 7:25 PM
To: jdev at jabber.org
Subject: RE: [JDEV] Jabber - Scripting Language

I was planning on adding VBScript based scripting to my client to allow
scripting of
Jabber and client items.  Basically for message rules, client behavior
mods etc.

It was basically going to broadly similar to the type of scripting you
see in IRC
clients to allow for bots, away systems etc.

It'll be interesting to see what comes of this discussion.

Ryszard

-----Original Message-----
From: jdev-admin at jabber.org [mailto:jdev-admin at jabber.org] On Behalf Of
Matthew Miller
Sent: 08 June 2001 00:40
To: 'jdev at jabber.org'
Subject: RE: [JDEV] Jabber - Scripting Language


I completely understand (and agree with) the need to finding the
problem-space before coming up with the solution-range.

I think we're showing that we have a problem space.  This is a reply
from one, although others have given more concrete examples.  My own
"gut feeling" is to allow for client-side customizations that don't
require a specific Jabber client to work.

I think we're also seeing that the solution to the problem starts to
generate more problems (at least right now).  For instance, how do these
scripts get executed or hooked-in?  If it's through embedding, how do we
protected against "virus-empowering", if it's even a real problem?

But since the behavior of BOTH the client and server are well-defined, I
believe we should have some facility to uniformly define an "interface
model" (at least for one if not both).  The interface model (be it
DOM-like or IPC-like) can lead to better-designed clients, that fullfil
the goal of Jabber being a solid, flexible, and extensible framework for
real-time messaging.

By defining a standard interface model, this could start with better
design on clients, by saying "hey, this client supports the same
interface model as other clients, so you don't have to learn a whole new
API just to customize me".  From here, we could easily move to an
embedded scripting model that allows for "applications" that simply rely
on the ("enhanced"?) Jabber client as its platform.

Anyways, besides the scripting thing being a "cool geek thing", there
are legitimate uses and needs for it: if there weren't why allow
scripting of e-mail or IRC clients?

OK, I'll get off my soap-box now.  Enough evangelizing for today, I
think...(-:

Matt


-----Original Message-----
From: Emswiler, Mike [mailto:MEmswiler at protrader.com]
Sent: Thursday, June 07, 2001 15:55
To: 'jdev at jabber.org'
Subject: RE: [JDEV] Jabber - Scripting Language


And of course, I've always loved the idea of just sending around script
embedded in XML and having clients execute it!  Really handy for
"roll-your-own" forms and workflow applications ... but horribly
insecure... JabberVirus anyone?

Thanks,
MikeE

-----Original Message-----
From: stpeter [mailto:stpeter at jabber.org]
Sent: Thursday, June 07, 2001 5:33 PM
To: 'jdev at jabber.org'
Subject: RE: [JDEV] Jabber - Scripting Language

I agree that something XML-related would be best. But I feel we need to
determine what the problem-set is before we settle on solutions.

Peter

On Thu, 7 Jun 2001, Matthew Miller wrote:

> Here's my $0.02...
>
> Jabber's protocol is described in XML, right?  And there's currently
> something called the Document Object Model, right?  Which defines an
> interface for events?
>
> Although Jabber isn't a Document-centric environment, a DOM-like model
(with
> events) could be fairly easily defined, and isn't that hard to
> execute.
I'd
> like to provide an example to this, but the software I'm working on
belongs
> to my employer.
>
> Anyways, why don't we look into something DOM-like?  This is basically
point
> 2), just a little (OK, a lot) more object-centric that simply an
> "interface".
>
> Like I said, that's just my $0.02...
>
>
> Thanks,
>
> Matt
>
> -----Original Message-----
> From: Stephen D. Williams [mailto:sdw at lig.net]
> Sent: Thursday, June 07, 2001 14:01
> To: jdev at jabber.org
> Subject: Re: [JDEV] Jabber - Scripting Language
>
>
> "Emswiler, Mike" wrote:
> >
> > I would suggest that Jabber take one of two approaches:
> >
> > 1. (the easiest) "adopt" an official language.  This should be an
> existing,
> > open-source, and preferably widely used language such as Python (my
vote)
> or
> > Perl (if we want to scare people away Jabber :)
> > 2. define a client scripting host interface.  This is a bit more
complex,
> > but far more flexible.  A binary specification for the host
> > interface
> should
> > be developed, allowing anyone to write a scripting engine "plug-in"
> thereby
> > allowing any scripting language to be used.  A particular client
> > (such
as
> > WinJab) could be used as a reference implementation for the client
> scripting
> > host interface.
>
> I was thinking of adding Python/JPython to a client I was building to
> provide scripting.  While I'm not a Python enthusiast, my friends have

> convinced me that I will be.  Since it has great support for Java, it
> makes a nice dual environment choice.
>
> The interface idea is definitely another useful possibility.
>
> >
> > Client-scripting can really be used by the client all over the
> > place,
but
> I
> > think the one feature most everyone wants is the ability to add
> > custom message handlers for automated or gui processing to easily
> > extend *any* client and to allow people to focus on the business
> > logic of their needs (client extensions) without worrying about the
> > client itself (Inboxes, History, notifications, blah blah) or which
> > client the user wishes
> (WinJab,
> > Gabber, etc.)
>
> Definitely, required at some point soon.
>
> sdw
>
> >
> > PGMillard had some good ideas on this front ... Peter ... was there
> > ever
a
> > JIG or something formed or proposed for this yet?
> >
> > Thanks,
> > MikeE
> >
> > -----Original Message-----
> > From: Todd Bradley [mailto:TBradley at jabber.com]
> > Sent: Thursday, June 07, 2001 2:26 PM
> > To: 'jdev at jabber.org'
> > 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.
> >
> > Todd.
> > _______________________________________________
> > 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
>
> --
> sdw at lig.net  http://sdw.st
> Stephen D. Williams
> 43392 Wayside Cir,Ashburn,VA 20147-4622 703-724-0118W 703-995-0407Fax
> Dec2000
>
>
> _______________________________________________
> 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
_______________________________________________
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

More information about the JDev mailing list