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

Chris Fanning christopher.fanning at gmail.com
Wed Mar 16 15:14:46 UTC 2005

Hi Matt,

Nice to meet you.

> 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).

Formidable work. I was suggested using jivesoftware when I posted to
jadmin about this but this must be a free software project.
I've looked at http://www.jivesoftware.org/ too.
Do you think there might there be code available on the .org site to help here?

> > Would it be reasonable to divide the development into three
> > seperate efforts?
> Definitely.
Good. That helps a lot.

> > 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.

Is this all specs. a developer needs to know to start to get something going?

> 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.
This sounds very attractive and I'll mention it but, to begin with,
I'd like to try and deal with minimum requirements. Once handed over,
the council can decide if it wants to explore other posibilities (that
would be nice).

> > 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
> have:
> [webclients] -(80)-> [Java servlet] -(5222)-> [xmpp server]
Right, that's how I imagined it but with a JWChat-derivitive instead
of the servlet.

> So, in our case, a Java Servlet is taking on the role of doing HTTP
> binding (but in a much simpler way).
When you say Java servlet, are you talking about Smack API ? If so, do
you think the web side can be more easily done using Smack?

> > 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.

In the office there are a group of women who attend the telephones.
I've already been told that there won't be a special workforce
dedicated to the IM interface. These women are going to have to juggle
their work between the incoming telephone and IM requests.
At the moment they have a propriety client on the desktop that runs
against the propriety software at the switchboard. It really is quite
an elaborate setup with many options.
We've spoken about the possibility of the women using two clients 1)
the switchboard client, and 2) the IM agent client. They then can
choose between one and the other according to queue length, or
wait-time or ...

I've been told that the switchboard software has a web interface too
(but they haven't bought it). Maybe the web client uses xmlrpc to talk
to the switchboard. If this were the case (I doubt it) we could
perhaps request queue state from the switchboard.

I get the feeling that the easiest (but not the most elegant) solution
is going to be something like 2 clients lined up side by side on the
desktop, and the women choosing petitions manually from one queue or
the other. Sounds like an ugly work around. Any suggestions?

> 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.

How would the work around affect the server component in regards to
routing to agents?

> More complex agent clients would implement all the
> extra stuff such as the ability to view what other agents are doing,
> etc.
This sounds something like an administrators client.

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

This is positive.


More information about the Standards mailing list