Contributing Software

Openfire Openfire Dev
1

Hi all,

The group that I am working with loved FastPath, except it had some big limitations (like no cross-domain widget support or ticket queues). Hence, we built a more customized package using:

Strophe.js

Openfire

Smack

Java Spring MVC Web Application

The Spring MVC Web Application is a dashboard in which agents can claim tickets in a ticket queue and talk to multiple incoming customers at one time.

Any recommendations for moving our project towards the Open Source community? Should we just throw the project up into some Githubs? Should we merge our MVC project into Openfire as a plugin? Any recommendations on which types of supporting materials we should create? Or possibly is there someone that should be contacted that would know what’s the best approach?

Thanks for the advice!

2

Is the source already available somewhere? Is there a demo installation? Does the project depend on Openfire? Or was it build on top of Openfire’s fastpath plugin? How’s it different from XEP-0142: Workgroup Queues? I too like the idea of fastpath, therefore I’m likely a fan of every project extending the idea. But ideally it’s designed as XMPP component which can be used with any XMPP server supporting external components.

Should we merge our MVC project into Openfire as a plugin?

What would be the advantage of merging? I like the idea of XMPP extension that don’t depend on a particular XMPP server.

Any recommendations on which types of supporting materials we should create?
As much high quality documentation as possible

2 Likes
3

The least you can do, is to post it as a document in the Community Plugins forums section and attach documentation and files needed to run it. I’m not sure about adding it as an official plugin as it involves parts of other software (licensing issues maybe?). Posting sources on the Github is always a good idea probably, as many will be able to find it even without knowing about Openfire/Spark and then will maybe find out about it. Though ideally it would be better to implement the XEP way as Flow mentioned, but it would probably be the longest route.

Can’t tell there is someone particular here to be contacted. Just a bunch of volunteers with no strict governmental body here. I think you’ve already got most of the feedback on this from Flow (and a bit from me)

1 Like
4

Thanks for the quick reply .

Is the source already available somewhere? Is there a demo installation?

We have been using the system for about a year or two now in production. The source and the demo can be made available but are currently not.

My query is an independent, preliminary investigation to see what kind of things we might need to do to prepare for the first open source release. I will have to check with my academic department before uploading code or releasing a URL to a demo server. An e-mail or message thread might be more appropriate for a detailed conversation.

However, to give you an idea of installation, essentially:

  1. Setting up Openfire + BOSH + Strophe | ExpertNotFound

  2. Then Tomcat + WebApplication war file

In order to give you an idea of what the web application is about, here is a screenshot from my localhost:

screenshot.png
screenshot.png1410×803 62.1 KB

Does the project depend on Openfire? Or was it build on top of Openfire’s fastpath plugin?

The project was built to be independent of Openfire. It is not built on top of the fastpath plugin.

We did, however, rely heavily on Smack (Jabber client) which may have one or two quirks when used with different systems (I haven’t tested with different chat servers yet).

How’s it different from XEP-0142: Workgroup Queues? … But ideally it’s designed as XMPP component which can be used with any XMPP server supporting external components.

So, if I remember correctly, the issue was small but significant. And perhaps with slight modification to our system, we could fit into that paradigm.

So, I wanted to use FastPath, but the big issue brought up by my client was that the Service in the Workgroup Queues do not broadcast requests from the Users. Instead, in the FastPath implementation, the Service cycles through all available Users and each User must “accept or reject chat requests”.

This causes delay time and confusion, especially when some of our Agents might be busy or unresponsive.

All of the other aspects of the web application use XMPP components. We automatically set up MUCs as our incoming tickets. The agents wait in an agent MUC until they claim an incoming ticket (aka join a MUC with a User).

What would be the advantage of merging? I like the idea of XMPP extension that don’t depend on a particular XMPP server.

Well, we built it as an extension that, in theory, doesn’t rely on any particular XMPP server. I was just wondering if we would have a better chance to get the community involved if we change the application to work as a plugin instead of a stand alone web application.

Cool. So it sounds like that we should go ahead and take the next steps then. Maybe upload the code to a public repository along with extensive, quality documentation? Also, it sounds like if we can alter the system to work with WorkGroup Queues and test using a couple XMPP servers we would have a higher chance of getting people interested.

Thanks for the advice! If you have any more, I would love to hear and to stay in contact. Otherwise, I guess, it’s time for me to polish off a few things and upload it.

5

We were pretty careful about the licensing and have consulted lawyers in the process, but, yes, that is something that I definitely think we should be aware of.

Cool. Yes, I will definitely revisit XEP Workgroup Queues. I have a vague remembrance of running into some barriers with them (see above post), but that sounds like the next step towards making the project more accessible/useful.

I really appreciate the feedback! This is great stuff .

6

I think i forgot to thank you for considering contributing your work to the community As Fastpath is aging and many issues are not fixed for years, some users will appreciate a modern and more reliable approach. Thanks!

1 Like
7

I was just wondering if we would have a better chance to get the community involved if we change the application to work as a plugin instead of a stand alone web application.
I’d expect your application to be more attractive to a wider group of possible users, if it’s not tied to any particular XMPP service. One big strength of XMPP is that, like every open standard, if done right it’s not causing a vendor lock-in.

8

Hi @nryckman,

I was trying to find some replacement of Spark & fastpath and take more of web based approach.

Could you give some timeline on when it could be made available as an open source.

I would love to try it out rather than building something from scratch.