Hi all, I am quite new to OpenFire.
I am trying to develop a collaborative application as follows:
client1:smartphone (aSmack) <-> OpenFire server <-> client1:web interface (Smack?)
now, I need to implement a system in which when a user sends a message to OF, he sees the message on the web interface, too (ie. he can “chat” with himself - or at least it should seem he is doing that)
I though about three ways to do this:
a single client on the server side implementation with a huge Roster of all the other users (smartphones): I would then filter from the server what should be shown to whom (1-many).
as many “users” on the server as the users on smartphones: this means each user will have in its Roster the other user (1-1), but then I would have a lot of clients to manage on the server side implementation…
a OF plugin, don’t know how/if possible…
Well, I hope at least something of this messy idea was clear, do you have any suggestion on how to implement this ?
You could do it with an api that each client accesses. So you connect the clients to both a custom backend and the openfire server. All recieved messages come directly through openfire, but all sends hit your api first. You give each client device type (web, mobile, etc.) a different login based on a pattern so it would be “userid-web@someserver” or “userid-mobile@someserver” but the actual specifics are hidden away from the user so the user only sees that they are logging in with their id and the api handles the rest. Now since all incoming connections are handled by your api, the api looks at what other accounts the user has logged into and sends the same message to that account on behalf of the user. You could also make it so that it can check to see if the recievers account is logged in in more than one place and have it send to each of those as well.
Seems like a bit much though.
I suppose the best approach would be something like what you suggest: an API that interfaces a username (like “John”) with one OpenFire user for each device (John_phone1, John_phoneN, …, John_web).
I will try a PubSub approach, storing everything as nodes with push notifications… sounds really cool.