My company www.objectsciences.com is really interested in adopting your platform. We need something to look at and decide if the Messenger API is worth waiting for. Do you have some api docs we could look at while you continue development of 1.1?
Hi,
The Messenger plug-in API for writing things like server-side chatbots is not planned for the 1.1 release. Most likely the 1.2 release will see the public release of this API.
In Messenger 1.1 we will be making available a simple API for plugging your own backend storage for user accounts and authentication. This would allow you to integrate Messenger with another user account system.
If you are not looking at backend storage integration, we can evaluate adding an API to provide the access you need in the short term if the scope of the API you need is small and well defined. Alternatively, if you are considering creating value added software around Messenger, we can discuss an OEM relatinship which could give you access to selected parts of the source of Messenger. This access would allow you to create custom administration interfaces, access internal server services, etc.
You can accomplish a lot with the client interface to Messenger by simply writing external XMPP clients. We provide the open source Smack Java client library for this purpose.
I suppose the long and the short of it is, we don’'t have any formal API planned for the near term (Messenger 1.1) but we are very flexible and would be interested in discussing what we can do to meet your needs.
-iain
Thanks for the feedback,
After looking at all the jabber servers out there. I still think your server is the best. My company is looking to deploy a messaging platform for a specific customer. Our first big requirement is event notification. Example: one of our machines on the network detects a hacker and 5 different sys admins need to be notified via Jabber. If the sys admins aren’'t online then the app server needs to email them, and send a message to their cell phone and pager.
Also we want to store Jabber messages that don’'t get received immediately but will get sent when sys admins log into the Jabber server again.
There will probably be other needs in the future. I want to get a better idea of what Jive Software expects in licensing if we needed access to parts of the source code.
Also what kind of licensing do you expect for server apis? Desknow has a simple one available. Can you offer something comparable?
Darian,
This sounds like an application that would be build using an XMPP client instead of a server component. That’'s a very common architecture, which is why we developed the Open Source (Apache license) client library url http://www.jivesoftware.com/xmpp/smackSmack[/url].
So, the client application would basically work as follows:
-
Have a “bot” account subscribed to the presence of all system administrators. The bot account stays persistently connected to the XMPP server.
-
Anytime a hack is deteced, the application checks the presence of the system administrators and then takes the appropriate action in terms of sending messages, sending emails, etc.
The Smack API is extremely easy to use, and the above could be accomplished in an hour or two of programming. If programming in Java doesn’'t work for you, there are many other client libraries in other languages available.
The only time you need to write a server module is when you need special logic not covered by the standard XMPP protocol. But, the standard protocol is already so extensible, that this rarely seems to happen. If you do end up needing to create a server module, we do have flexible licensing of source code available in the server.
Regards,
Matt
It’'s good to hear that you have flexible licensing available for the source code.
You say XMPP protocol is already so extensible. How would I extend it so that the server could filter messages for prohibited content and block messages if they contain prohibited content?
I can’'t think of a reliable way to implement that with the client API. Can this even be done with your server API if you have one?
Hi,
Filtering messages is definitely something you’‘d want to do on the server. It should be relatively easy to do this (it seems like a pretty well defined API as long as you are just looking at a message and returning a pass/no pass result). I’'ve filed a feature request in our issue tracker and tentatively scheduled it for 1.2. If this is critical and you need to deploy relatively soon, let me know and we can see what can be done to include the feature in time for your needs.
-iain