I’‘ve been using Whack to develop a gateway but I’'m missing the information that i know resides on the server. I need a mechanism for querying that info out of band from the XMPP stream.
Current I need access to:
roster database
presence database
Let me describe the details of each use case and perhaps a alternative will show itself.
Roster Database[/b]
Typically when a user registers with a gateway, they typically have already established contact lists on their account. When the user registers with the gateway it should query the JID of the user to determine if their rosters match and if they don’'t proceed with the subscribe/subscribed protocol for update a jabber roster. This should be done at most once during the initial registration and a periodic check should be made to make sure everything is in sync.
Presence Database[/b]
When the gateway comes online, it needs to check to see who’‘s online so they can log them into the legacy service. Messenger doesn’'t not send presence information until the client sends new information. This requires a user to change their status in order to log into the legacy system.
I’‘m not sure on the roster database part. One the presence – there’‘s a gateway JEP for client authors that specifies that the client has to notify the component that they should be logged in to the gateway. That’'s really the only standard approach possible when using external components.
Maybe the answer is that gateways shouldn’‘t be written as external components?? If the gateway was a plugin it would have full access to the user’'s presence and roster. This would preclude the gateway from working with other servers besides Jive Messenger, but any custom external component stuff we created (such as to handle presence) would lead to the same situation. The other option would be to create a new JEP to enhance external components for use by gateways.
I started with a plugin but Gato convinced me that an external component is the way to go. As for notifications, Messenger does deliver presence notifications. However, if the gateway dies and is restarted, all state is lost (unless the gateway maintains it). Roster information is roughly the same pattern, I don’‘t want to continually send subscribe messages to the client when they’'re already subscribed.
Just to update this thread. The other day we had a chat with Noah about these issues. Bottom line is that the gateway needs to keep its own track of the legacy contacts in the rosters of the XMPP users. And if for some weird (ie. unfrequent) problem the gateway was shut down when the user was sending an unsubscribe packet then the situation will be solved in the future when the user realizes that he is still receving presence notifications from users that shouldn’'t be in his roster in which case the user will send a new unsubscribe packet.
In summary, I like the idea of having the gateway framework running as an external or internal component depending on the gateway load or other circumstances.