[Standards-JIG] jep-0142 and a city council workgroup

Matt Tucker matt at jivesoftware.com
Tue Mar 15 16:27:52 UTC 2005


As one of the authors of the JEP, I hope I can help answer your
questions... :) We also have an implementation of the JEP with Jive Live
Assistant (http://www.jivesoftware.com/products/liveassistant).    

> 0142 talks about roles. http://www.jabber.org/jeps/jep-0142.html#roles
> Would it be reasonable to divide the development into three 
> seperate efforts?


> 1. user client: web (perhaps stem from 
> http://jwchat.sourceforge.net/ ?) This is perhaps better only 
> as simple interface as not to confuse the public.

I think that the vast majority of the implementations will go this
route. In fact, you don't even need a full XMPP client for the web side.
It doesn't need to be able to handle rosters, etc -- it just has to have
the ability to make a request to a workgroup queue, wait to be routed,
and then join a group chat. I imagine that JWChat could be customized to
do this, but I'm not familiar with that code.

There are also cases where letting users talk to a workgroup through a
full IM client makes a lot of sense. For example, the IT department
could be in everyone's roster in a large company's internal IM system.
Double clicking on the IT department in the roster would route users to
the next available IT support agent in order to help the user get their
problems resolved.

> 2. service: this is a jabber server, right?
> I'm at a loss here because of my lack of jabber knowhow.
> It could be put behind the corporate firewall letting port 80 
> inside from the web.

Right, it's a component inside of an XMPP server. The server could be
listening on port 80 using HTTP binding, or could be communicating with
clients over the normal XMPP port (5222). In Jive Live Assistant, we

[webclients] -(80)-> [Java servlet] -(5222)-> [xmpp server]

So, in our case, a Java Servlet is taking on the role of doing HTTP
binding (but in a much simpler way).

The server component is one of the more complex pieces. It has to
understand how to route to agents based on availability, skills, etc. It
might not be hard to do a simple implementation that does something like
round-robin routing, though I'm not sure how useful that would be in a
real-world deployment. 

> 3. agent client: desktop application (stem from psi?) 
> Mutliplatform for future gnu/desktop migration.

Right, in most cases you'd definitely want agents to use a full desktop
client. A simple version would be customizing an existing client (as you
suggest) to support accepting incoming offers and then routing to a
group chat room. More complex agent clients would implement all the
extra stuff such as the ability to view what other agents are doing,

> I see a lot of work here. For example, the agent client needs 
> to fit in with the council's end-users requirements and the 
> jep has some MAY's that seem to make client specification one 
> of the first steps to be attended.
> Another requirement may be that the end product be 
> sufficiently generic to make it useful for others in the community.
> What scope would this project have? Is it just simply out of 
> the question? On the wrong track? Technologically inmature? 
> Worth looking into?

I'm not sure what the answer is on these questions. We've spent nearly
two years working on the JEP and our initial implementation of it with
two full time developers. However, our implementation is a lot more
ambitious than what would be strictly needed for JEP compliance. :) We
crafted the JEP that way deliberately. We wanted it to be relatively
simple to become compliant with the JEP, but for it to also offer enough
flexibility to base some truly robust tools on.  

In any case, we (the JEP authors) would definitely welcome collaboration
on the JEP and are happy to answer questions about it.


More information about the Standards mailing list