[JDEV] Jabber - Scripting Language

Thu Jun 7 18:45:25 CDT 2001

I can see the need for server-side scripting, but I'm 
wondering if defining a client-side scripting standard is 
necessary.  Seems to me that you let clients implement 
whatever they want, however they want.  All of the 
client-side features described below can be done without a 
standard.

I may be completely wrong here, since I haven't, like, 
actually really looked at it, but I had the impression that 
mod_filter was some sort of server-side routing-rule 
mechanism?  Or is that incorrect?

=Bill

On Thursday 07 June 2001 15:46, you wrote:
> 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
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev