Well this is wierd I was trying to set this up so that I could get the log output on that run and I ended up changingtoand adding a preinitialize function of:protected function preInit():void { templateID = Application.application.parameters['room']; token = Application.application.parameters['token']; }oddly enough it now works like a charm now. It is still disconcerting that I was able to actually enter the room even though my token was somehow corrupted (that probably isn't intened behavior)....

Typically each pod will setup its own collection node so you really don't have to worry about it. If you are writing new pods from scratch unless there is some data dependancy between pods then each pod having thier own collection node is typically how it is broken up. You can't really be logged into multiple rooms under one application (that I know of) so yeah only one room for all of them. Hope that helps.

This actually "could" be very simple. I say could because I am not precisely sure of what other effects this could have but if you check the SimpleChatModel and change the node setups within: protected function onSynchronizationChange(p_event:CollectionNodeEvent) and change the storage scheme from NodeConfiguration.STORAGE_SCHEME_QUEUE to NodeConfiguration.STORAGE_SCHEME_SINGLE_ITEM the chat items won't persisit on the server side. And only the very last message should be in those nodes. I hope ...

quote:Originally posted by: Nigel Pegg If that's not enough, we are considering adding HTTP APIs sothat you would be able to have your own server subscribe to theroom and retract the chat items, on any schedule you'd like. Wouldthat fit for you?I'd like to also echo the sentiment for a fully functionalHTTP API. I find it critical for the server to have the ability toact as a normal user in terms of the data sent back and forth(including permissions as owner) as well as room setup andmaintenance ...

Nigel,Thanks for the reply. I never expected interaction on aSaturday of all times. I have just a few further comments :).1) I thinks I can live with that. That makes some sense. Ididn't realize you were following the XMPP spec, that gives me someinsight. I think deleting and restarting the Node seems like a goodway to accomplish that. Let's run through it so i understand thisbetter. If i want to completely clear a node I issue a:collectionNode.removeNode(nodeName); as the Owner followed byacoll...