One thing I think you might have missed is to add
import org.davekeen.xiffer.model.XMPPProxy
near the start of StartupCommand.as - trying to build the project without it results in “Error: Call to a possibly undefined XMPPProxy” after registering the new proxy.

Other than that, works like a charm!

There aren’t any hard and fast rules to this - its really up to you how you split up the proxies. However, here are some things that I personally think about:

o If a proxy contains methods that operate on a specific logical concept then seperate it out. For example, in an address book application all the methods to do with contact CRUD might be in ContactProxy and all the methods to do with import/export might be in ImportExportProxy.
o I often put things that access different remote services into their own proxies. For example, if our Jabber application also got information about users via a web service these methods might well be in their own proxy.
o Sometimes there is a fairly direct map between the services in your proxy, delegate and backend so I try to keep these synchronised. For example, if I have a large AMFPHP application I’ll have UserProxy only calling methods in UserMethods.php, etc. This means that the way the backend is compartmentalised sometimes dictates the way the proxies are split.
o Its often good to try and get all similar functionality into a single proxy for purposes of re-use. I always try to split them up in such a way that if I decide that I want to use ‘UserProxy’ in a new application it contains everything to do with users.

But, when you get right down to it, split the proxies however you feel most comfortable - they are there for your convenience!

Hope that helps,

Dave