Namespace extension data not persisting to subsequent MUC sessions

XIFF
1

Hi,

we are creating an application that requires custom namespace extensions, and we want the data in these extensions to persist to subsequent chat sessions just as the basic text chat is handled; however, we have been unable to get it to work. We need to implement a purely client-side means of archiving and regurgitating the data rather than using server extensions. I need to look into it further, but it seems like empty messages are being returned for subsequent sessions.

For example, this is roughly how our data looks:

Are we missing a finer point of getting things to persist?

This post addresses the same problem.

And this may have some correlation as well, although it doesn’'t address extensions explicitly:

History Support in Multi-User Chant This

Thanks,

Nick

2

I do not recommend customizing the XML as we use the XMPP specification for all of our parsing. I would look into how you can leverage the specification to do what you want. The RFCs, sachemas, etc can all be found here: http://www.xmpp.org/.

I am confused as to why you are looking to extend the namespace as well when you only need to save the data to a file. You can actually view all XMPP traffic in spark if you go to the advanced section during login and turn on debugging.

3

Great point about sticking to the spec.

If an XMPP client is submitting XMPP compliant data within the “message” tag/namespace will it be stored by Openfire as part of the conversation/MUC?

I believe it is possible to send arbitrary data (e.g., base64 data) within the message. This, of course, is a huge advantage of XMPP because it allows the XMPP client to do creative things with content inside a message.

While Openfire is XMPP compliant, Openfire may or may not store the “extended” data in the database for the conversation/MUC.

This leaves the question:

WIll Openfire store data other than the contents in the database as part of the conversation/MUC log? If so, what extension/specification will allow for this?

An example of this might be a whiteboard that sends drawings (circles, arrows) encoded as XML. Where should the drawings be put so that Openfire stores them (in their XML represenation) as part of the chat?

Thanks.

4

Hi Kevin,

with respect to a whiteboarding app, there are some proposed specs for whiteboarding but nothing on the books just yet. If you have some ideas on how to leverage other existing and supported specs, I would appreciate it (maybe jabber:x:data ?).

Ideally the whiteboarding data will be retained from session to session by just selecting Log Room Conversations" from within the Openfire admin; however, our custom data is lost between sessions with this setting. I haven’'t yet looked inside of the server to see how it decides what to keep and what to drop, but I suspect it is rather particular. Regardless, I am considering less than elegant workarounds.

Thanks for the spark debugging tip - I had been doing that in the Flash IDE but the Spark debugger is much better.

Thanks!