We are working on a medium scale Openfire customization project for our client (we’ll refer to the client as “abc” in this document).
The purpose of this document is to briefly present the requirements to you and get your insights, feedback and suggestions regarding:
Design decisions (within and outside the realm of Openfire)
Quickest vs. Best approach to use
Perhaps, a ballpark estimate of how much time such a customization can take.
High level project requirements
Allow users external to “abc” to connect with agents representing “abc”.
External users can make use of their respective chat clients (Yahoo, MSN, ICQ, AOL etc) to connect with agents of “abc”. [ IM Gateway plugin helps here ]. They will also be provided with a web based chat client [ Fastpath Web ?? ]
Agents of “abc” will NOT (suggest otherwise if needed) be associated with any external/proprietary (Yahoo, MSN, ICQ, AOL etc) services. In other words, agents of “abc” will not have rosters for the IM Gateway plugin.
Both external users and agents of “abc” can initiate a chat session.
External users will connect to published accounts of proprietary services, for instance, abc-support1@yahoo.com, abc-support2@yahoo.coom, abc-support33@hotmail.com etc. An external user can get connected to any available “abc” agent seamlessly.
All “abc” agents can initiate a chat session with any external user regardless of the proprietary client he/she is using. This also includes the web based chat client.
Routing rules (as available in Fastpath) are needed.
NOTE: Please see the attached image for an understanding.
You will have to modify IM Gateway a lot (btw, this project is now named Kraken and has its own site and svn and bug tracker at sf.net). Every agent will have to have an account in every legacy network (ICQ, MSN, etc.). And IM gateway should only let them receive messages and not add any contacts to their rosters. I think client modifying would be needed also.
*abc-support1@hotmail.com, abc-support1@yahoo.com *are present in openfire against an openfire/jabber account.
Representatives of “abc” company will only have simple jabber/openfire accounts
Modify the Fastpath workgroup feature to support and add an attribute “multiplexer” to the workgroups (i.e. either a workgroup is a normal workgroup or it is a multiplexer workgroup)
The sole job of the virtual agents/accounts in the multiplexer group will be to act as a mediator between the external users’ accounts and the “abc” agents’ accounts (say abc-agent1@abcopenfire.com, abc-agent2@abcopenfire.com … )
Please see the attached image for a better understanding.
Do you think this is the right way to go? Are there better alternatives out there? I am not much informed about the plugin architecture and design of openfire and its plugins.
I doubt it will be answered. Your task is too complex and unusual. You can try moving this thread to Openfire Dev forum, but probably you won’t get more attention. Most of us are just simple users and admins using Openfire/Spark.
