xmpp in javascript

29 views
Skip to first unread message

Steve Ivy

unread,
Jun 25, 2008, 4:28:54 PM6/25/08
to diso-project
http://zeank.in-berlin.de/jsjac/

thinking this could be an interesting way to get notifications into a
web-based "social inbox"...

--
Steve Ivy
http://redmonk.net // http://diso-project.org
This email is: [ ] bloggable [x] ask first [ ] private

Peter Saint-Andre

unread,
Jun 25, 2008, 4:47:53 PM6/25/08
to diso-p...@googlegroups.com
On Wed, Jun 25, 2008 at 01:28:54PM -0700, Steve Ivy wrote:
>
> http://zeank.in-berlin.de/jsjac/
>
> thinking this could be an interesting way to get notifications into a
> web-based "social inbox"...

Yepper.

IIRC, the folks at Chesspark also have a JavaScript library that they'll
be open-sourcing before long.

Peter

Blaine Cook

unread,
Jun 25, 2008, 4:50:00 PM6/25/08
to diso-p...@googlegroups.com
heh - i figured everyone knew about these projects. ;-)

I've been playing with getting cross-domain requests to work with jsjac. BOSH defines an alternative syntax that enables cross-site scripting (wraps responses in _BOSH_('$body') instead of just returning $body so that they can be eval'd) to take advantage of optimized jabber servers holding tens of thousands of [relatively] inactive but connected clients open, but jsjac doesn't support it. Openfire does on the servers side, not sure about other servers.

My alternate approach is to do the same thing, but host the script on the jabber server --- openfire doesn't support this as far as I can tell, and ejabberd should, but the mod_http_fileserver module is broken in the OS X installer version of ejabberd.

The often-quoted alternative is to setup a proxy through apache or some other web server, but that completely defeats the purpose of using an event-based webserver like one of the nice jabber servers.

b.

Steve Ivy

unread,
Jun 25, 2008, 4:59:38 PM6/25/08
to diso-p...@googlegroups.com
Blaine,

Pardon my ignorance, but can you explain how using XSS facilitates this?

> take advantage of optimized jabber servers holding tens of thousands of [relatively] inactive but connected clients open

Also, which servers can support JSJaC/BOSH right now?

Cheers,

--Steve

Steven Livingstone-Perez

unread,
Jun 25, 2008, 5:04:56 PM6/25/08
to diso-p...@googlegroups.com

Just to bring up something I had mentioned a while back (and one or two others had too)…

 

… as XMPP, in the way the discussions are going, would be a central part of the architecture, I am a little concerned its complexity and implementation could be an issues for those who don’t have lots of time to through at projects looking to quickly build upon the architecture.

 

It is a fantastic technology, but I have also found a lot of variations in implementation (as you mention below) - which is not in itself a problem … it’s  more that due to the complexity of a XMPP server it’s quite hard to just add a new module to support it in a few days.

 

Something that does appeal is lightweight XMPP servers – perhaps a core library with everything else optional – the specs seem to have been developed that way. If that exists I’d like to know about it as I am using Openfire ( EJabberd looks similar) and it’s quite a lot to take in.

 

Regards,

Steven

Peter Saint-Andre

unread,
Jun 25, 2008, 5:03:42 PM6/25/08
to diso-p...@googlegroups.com

Jack Moffitt corrected me -- it's been open source forever:

http://www.chesspark.com/play/scripts/strophe.js

Jack reports that they are currently making the library simpler and
more modular, and will soon move it to launchpad.net.

/psa

Steve Ivy

unread,
Jun 25, 2008, 5:06:04 PM6/25/08
to diso-p...@googlegroups.com
The way I'm looking at it right now, an XMPP server may never be a
component that a user has to install/configure, just as few will have
to install/manage an openid provider. But if we define expected
behavior/protocols that use XMPP, then there is an opportunity for
messaging providers to step in and run DiSo-capable XMPP servers.
Ideally, we can design client usage patterns and formats that require
little of the provider other than handling the protocols - IE, if you
support pubsub, bosh, and openid login (does anyone?) then it will
"just work".

On Wed, Jun 25, 2008 at 2:04 PM, Steven Livingstone-Perez
<web...@hotmail.com> wrote:

> … as XMPP, in the way the discussions are going, would be a central part of
> the architecture, I am a little concerned its complexity and implementation
> could be an issues for those who don't have lots of time to through at
> projects looking to quickly build upon the architecture.

> Regards,
>
> Steven

Steven Livingstone-Perez

unread,
Jun 25, 2008, 5:13:32 PM6/25/08
to diso-p...@googlegroups.com
Fine. I'm working on something I hope to talk to enterprises about (a long while down the line) and I just want to stay on top of what I may have to tell them if I went down the XMPP route.

-----Original Message-----
From: diso-p...@googlegroups.com [mailto:diso-p...@googlegroups.com] On Behalf Of Steve Ivy
Sent: 25 June 2008 22:06
To: diso-p...@googlegroups.com
Subject: [diso-project] Re: xmpp in javascript

Stephen Paul Weber

unread,
Jun 25, 2008, 5:51:43 PM6/25/08
to diso-p...@googlegroups.com
> Something that does appeal is lightweight XMPP servers – perhaps a core
> library with everything else optional – the specs seem to have been
> developed that way. If that exists I'd like to know about it as I am using
> Openfire ( EJabberd looks similar) and it's quite a lot to take in.

As far as servers, ejabbered is pretty easy to install and config on a
modern linux system (I've done it twice). As far as clients, python
and ruby have nice ones, and work on a modern PHP one is underway.

--
- Stephen Paul Weber (Singpolyma)

Web: http://singpolyma.net/
Twitter: http://twitter.com/singpolyma
IM: singp...@gmail.com

Steven Livingstone-Perez

unread,
Jun 25, 2008, 6:05:18 PM6/25/08
to diso-p...@googlegroups.com
The installation of Openfire was also very easy. A number of clients I have looked at are skewed towards chat and abstracting the core messaging libraries can be tricky (which is why I like that the Chesspark client is becoming more modular).

I just know I don't really need many of the modules it comes with (and possibly support)... in fact the XMPP Core messaging (3920) + PEP would be good enough for me.


-----Original Message-----
From: diso-p...@googlegroups.com [mailto:diso-p...@googlegroups.com] On Behalf Of Stephen Paul Weber
Sent: 25 June 2008 22:52
To: diso-p...@googlegroups.com
Subject: [diso-project] Re: xmpp in javascript

Blaine Cook

unread,
Jun 25, 2008, 8:22:13 PM6/25/08
to diso-p...@googlegroups.com
On Wed, Jun 25, 2008 at 1:59 PM, Steve Ivy <stev...@gmail.com> wrote:

Pardon my ignorance, but can you explain how using XSS facilitates this?

If you have a Jabber server at xmpp.example.com, and your website lives at example.com, then you can't use JSJaC or any other javascript library to pull XMPP originated content from xmpp.example.com, since the browsers' cross-domain security features won't let you.

If you use something like the JSONP approach, where the <script> is loaded from xmpp.example.com, then you can push events over the wall to example.com and have full integration.
 
Also, which servers can support JSJaC/BOSH right now?

I'm sure most of them do --- Openfire and ejabberd definitely do, but the cross domain issues are very problematic. Most people currently proxy BOSH through apache to either Openfire or ejabberd.

b.

Steve Ivy

unread,
Jun 25, 2008, 8:27:03 PM6/25/08
to diso-p...@googlegroups.com
Yeah, I tweaked my FF to allow cross-domain scripting, but still get
this in my console from jsjac:

[Exception... "Component returned failure code: 0xc1f30001
(NS_ERROR_NOT_INITIALIZED) [nsIXMLHttpRequest.send]" nsresult:
"0xc1f30001 (NS_ERROR_NOT_INITIALIZED)" location: "JS frame ::
file:///Users/sivy/Downloads/jsjac-1.3.1/jsjac.js :: anonymous :: line
215" data: no]

--

David Orchard

unread,
Jun 25, 2008, 8:39:05 PM6/25/08
to diso-p...@googlegroups.com
There was some discussion about FF3 supporting the W3C Access Control for Cross Site Requests spec ( http://www.w3.org/TR/access-control/) but the David Baron's Interview (http://www.w3.org/QA/2008/06/interview_david_baron_on_firef.html) didn't really say whether "supporting" = shipping in FF3.
 
Cheers,
Dave

Josh Patterson

unread,
Jun 25, 2008, 9:38:07 PM6/25/08
to DiSo Project
I think browsers are gonna have to come around to the fact that sooner
or later the cross domain stuff needs to happen (of course with
security, etc).

FF3 has coming support for crossdomain scripting via adding in the
proper headers on the server of the remote domain, although im not
sure its in the current release. I talked to one of the FF coders,
John Resig, about it, and he has some examples of it up on his site.

Of course flash has it with the crossdomain.xml file on the server
side, which i think is sorta funny that flash allows it but the
browser won't allow it for scripting. A trick some people use for
cross domain client side js stuff is to have a flash proxy file which
is essentially a XMLSocket / XMLHTTPRequest that can do cross domain,
as long as the crossdomain.xml file is on the server of the remote
data endpoint (you make a call to the flash proxy via js on the
client.) --- I'm probably going to use some of this in some near
future features for a project, might be applicable here if you aren't
too hung up over flash.

Of course there is the security minded google caja in development, but
i dont know how far they are along, and I'm not completely sure how
they will deal with cross domain issues. I'm still waiting for it to
settle out some more.
http://groups.google.com/group/google-caja-discuss


Josh Patterson
http://jpatterson.floe.tv

On Jun 25, 8:22 pm, "Blaine Cook" <rom...@gmail.com> wrote:
> On Wed, Jun 25, 2008 at 1:59 PM, Steve Ivy <steve...@gmail.com> wrote:
>
> > Pardon my ignorance, but can you explain how using XSS facilitates this?
>
> If you have a Jabber server at xmpp.example.com, and your website lives at
> example.com, then you can't use JSJaC or any other javascript library to
> pull XMPP originated content from xmpp.example.com, since the browsers'
> cross-domain security features won't let you.
>
> If you use something like the JSONP approach, where the <script> is loaded
> from xmpp.example.com, then you can push events over the wall to
> example.comand have full integration.

Blaine Cook

unread,
Jun 25, 2008, 10:54:20 PM6/25/08
to diso-p...@googlegroups.com
On Wed, Jun 25, 2008 at 2:04 PM, Steven Livingstone-Perez <web...@hotmail.com> wrote:
>
> It is a fantastic technology, but I have also found a lot of variations in implementation (as you mention below) - which is not in itself a problem … it's  more that due to the complexity of a XMPP server it's quite hard to just add a new module to support it in a few days.

Agreed - the problem that I see is that XMPP is awesome, but as a friend mentioned, it's kind of like having the first telephone right now. It's great, but hard to justify the cost associated with a pretty useless object. I think we'll find this drop off pretty quickly as a barrier, once a few more people have adopted XMPP.


> Something that does appeal is lightweight XMPP servers – perhaps a core library with everything else optional – the specs seem to have been developed that way. If that exists I'd like to know about it as I am using Openfire ( EJabberd looks similar) and it's quite a lot to take in.

One thing you might look at is the component spec (XEP-0114 and the newer one XEP-0225) --- the way I like to present it is "CGI for Jabber"; essentially you throw out the session manager and just handle raw XMPP packets. You connect a bunch of components to your jabber server and receive every packet for the domain (or jid) that you've said your component will handle, including <iq> and discovery stuff. It means you have to handle presence packets, but it means you can do anything with the domain.

b.

Peter Saint-Andre

unread,
Jun 26, 2008, 4:51:54 PM6/26/08
to diso-p...@googlegroups.com
On Wed, Jun 25, 2008 at 07:54:20PM -0700, Blaine Cook wrote:
> On Wed, Jun 25, 2008 at 2:04 PM, Steven Livingstone-Perez <
> web...@hotmail.com> wrote:
> >
> > It is a fantastic technology, but I have also found a lot of variations in
> implementation (as you mention below) - which is not in itself a problem ???

> it's more that due to the complexity of a XMPP server it's quite hard to
> just add a new module to support it in a few days.
>
> Agreed - the problem that I see is that XMPP is awesome, but as a friend
> mentioned, it's kind of like having the first telephone right now. It's
> great, but hard to justify the cost associated with a pretty useless object.
> I think we'll find this drop off pretty quickly as a barrier, once a few
> more people have adopted XMPP.

I always find such statements amusing, because when I joined the Jabber
community there were probably 500 users. Now we have what, 50 million?
But they're not all federated yet, which is why I keep pushing for more
of the large services to interconnected. Slow organic growth has been
the watchword for the Jabber/XMPP world since 1999. All this recent
attention and buzz is unfamiliar to our little community. :)

/psa

Matthew Terenzio

unread,
Jul 1, 2008, 10:35:34 PM7/1/08
to diso-p...@googlegroups.com
I'm using HTTP-BInding via JSJAC for a twitter web IM client. Posts go out via regular twitter web api since that part is down at twitter lately.

just a spare time toy at the moment (bugs and all)  but free to give it a twhirl at http://twitter.im/register/
Reply all
Reply to author
Forward
0 new messages