So I came up with an idea to put together both techologies: Grails/Groovy and XMPP.
The main idea is to create a grails plugin that eases the development of real-time xmpp based web applications.
The plugin can be built upon the Smack API and would provide XMPP/IM based services to grails applications.
Below the list of functionalities I´d like the plugin to provide divided in two distinct approaches:
Approach 1: One Roster per application
- Provide the grails application with a Roster
- The Roster (might) automatically connect to a xmpp server and broadcast its presence on application startup - Bootstrap (XmppBootstrap) or InitializingBean??
- Roster configuration ( jid, pwd, server host and port, etc ) should go to?? Config.goovy
- Provide a XmppController with Roster functionalities
- Provide a XmppServices with Roster functionalities (sending messages, changing roster status, sending presence packets, accepting and sending invitations, etc)
- Auto detection and registering of xmpp message listeners
- Repass grails proxy configuration to xmpp connection settings org.jivesoftware.smack.proxy.ProxyInfo
- Ability to expose Service´s methods as IM commands (something similar to what friendfeed is doing). The method name would map to the IM command and would be automatically invoked when incoming messages starting with "@
" arrived
org.jivesoftware.smack.ConnectionConfiguration
Another approach would be having multiple Rosters (I´m calling them xmpp bots) including the functionalities above mentioned and:
- New script to create xmpp bots - i.e. grails create-xmpp-bot;
- Bots would be configured via static properties: jidId, pwd, host, etc
- The plugin would auto-detect these bots (grails-app/xmpp-bots/*XmppBot.groovy), create the respective spring beans, register them as message listeners, initialize them at application startup, etc
I´ll probably go with the first approach as it makes more sense to me. It´s difficult to imagine needing to have more than one agent per application.
Another aspect that should be taken into consideration is how the subscription will be handled.
I´ve already started the coding but I still have lots of design decisions to make and lots of work too - haven´t got enough time to dedicate to this parallel project lately.