> On Mon, Aug 24, 2009 at 8:05 AM, DerikB<dbad...@temple.edu> wrote:
> > Any chance we'll see the new queue selection feature for other chat
> > clients? I have a lot of colleagues that would love that one, but they
> > are all the ones who use a client so they can monitor personal
> > accounts too.

> We'd really like to bring this feature, and other special LibraryH3lp
> features, to external clients in a graceful way.  A relatively
> complete answer is unfortunately kind of long and involved, but here
> goes.

> First up, users of external clients can *sort of* do queue selection
> now in two ways.

> 1) If using a multi-account client like Pidgin (multi-protocol), Adium
> (multi-protocol), or Psi (jabber-only), you can pretty much do the
> same thing by assigning users multiple LibraryH3lp accounts.  Then,
> assign the accounts to different queues using whatever staffing model
> you need, and train the users to enable and disable their different
> accounts to suit different purposes.

> 2) Users can select queues in the webchat client, since the queue
> settings stick with the user until they re-set them deliberately,
> again using the webchat client.  So, they'd sign into the webchat just
> long enough to select the desired queues (and de-select the queues not
> desired), then they'd logout of the webchat client and login to their
> external client.  They can also probably sign into the webchat at the
> same time as they're signed in with their external client long enough
> to pick their queues, but it's a bad idea in general to stay signed
> into the same account in two clients as a general practice.

> Obviously, these solutions aren't quite ideal, and #2 in particular
> will be error-prone since users may not remember the state of their
> queue selection between logins, and they do not have an easy way to
> check in their external client.

> SO.  How about making queue selection work nicely in the external
> clients themselves?   This gets into a lot of the design philosophy
> behind LibraryH3lp.

> One of the design goals we had with LibraryH3lp from the beginning was
> to limit customization of external clients to plugins.  LibraryH3lp's
> predecessor, pidgin4lib, was a fully customized Pidgin client, and it
> was a pretty big ordeal to keep it updated, patched, and correctly
> configured across all the computers required for NCSU, UNC, and Duke.

> With LibraryH3lp, the only customized external client piece is a
> plugin for Pidgin, and this plugin has continued to work with all
> releases (so far, knock on wood) of Pidgin.  The unfortunate part of
> Pidgin's plugin design is that it's really hard/impossible to modify
> Pidgin's GUI in a plugin, so we can't make big, friendly buttons
> inside the chat window to support advanced LibraryH3lp features.

> Now, the good news!  The XMPP (Jabber) protocol standards are full of
> very nifty things, and these standards actually provide for all kinds
> of things that we do with LibraryH3lp (transfer, queue selection,
> various other commands).

> So, why aren't the external clients able to do these things already?
> It's because most Jabber clients do not actually implement all the
> required standards to make these things work.

> The client that comes closest right now is Psi, a very heavy-duty XMPP
> account for serious Jabber people.  It only works with Jabber
> accounts, so users can't also be signed into their personal AIM, etc,
> accounts with it.  In fact, Psi already supports libh3lp transfer (but
> recipients of transfers do not yet receive the full roll-back of
> transferred chats), email transcript, and tag for followup.  Even with
> Psi, queue selection doesn't work quite yet, but this is because of an
> Ejabberd (libh3lp's Jabber server) bug, not anything lacking in Psi.

> A long-term LibraryH3lp goal is to try to bring Pidgin into better
> Jabber compliance with these extended standards, so that it can be
> used more gracefully with advanced libh3lp features.

> To try to sum up, these sorts of features will hopefully be available
> in at least some external clients eventually, but it's a long road.

> Hope this helps!

> Best,
> -Pam.