Extending User Data

I am wanting to extend the user data fields that are sent with to clients (and customize a client to handle the extra data). This extra data will be sitting in the same database and tables alongside existing Wildfire data. Somewhat new to XMPP, is there a standard way to do this (without stomping on the toes of this protocol “standard”)?

Any discussion, tips, or pointers to recommended reading would be most appreciated!

Thanks!

Hi eawise,

is there a standard way to do this (without stomping on the toes of

this protocol “standard”)?

Yes, probably the best way to do this would be to use a VCard. Take a look at the documentation of the url=http://www.jivesoftware.org/smack/Smack[/url] library on how to use it.

Hope that helps,

Ryan

Thanks Ryan!

How “real-time” is vCard data on the chat client? For example, does the client typically have vcard data about all users in its roster…and if it does, how often do typical clients refresh it? Or is the model more around getting vcard data only when the client (or person using the client) requests it?

Thanks for your input.

Hi eawise,

I would lean towards only requesting the vcard information when it is needed, i.e., when the user requests it. Prefetching all that data could be quite costly in terms of bandwidth and memory consumption.

Hope that helps,

Ryan

Very true. My needs are around having a couple small fields which I want to “live” with every user in the roster at all times. Given this fact, dumping a whole vcard seems a little excessive, as you said, in terms of memory/bandwidth. With this in mind, should I be leaning towards another method, other than vcard to “extend” user info?

What sort of data are you referring to?

A couple of user specific guids to allow the client to interact with another application.

Any thoughts?

I still think Ryan’'s idea for vcard would be the simplest. Alternatively, you could create your own protocol extension. Only your client would be able to understand it, but it would be another valid approach to the problem.

Regards,

Matt