best practices to handle (send/recieve) Messaging (BlazeDS-Turnkey) in pureMVC?

[karfau]

Well I have kind of an idea that I like this framework very much, so thanks for this great (frame-)work.

This is my first attempt to build an application with the pureMVC-framework. The goal is a "platform" to play different games (included as some kind of plugin, the first one will be a-kind-of-Monopoly) with other online users. The server-backend we use is the blazeds-turnkey.

So I did a lot of modelleing for getting the idea of how to do things the right way and had a bit of understaning it better (i think).

But one thing remained unclear: what is the best way/practice to handle (react upon retrieving / send) Messages of the kind BlazeDS offers.

So sending messages from one client targets all other clients wich subscribed the destination/"channel" (eventually with the right subtopic) wich, inside the application we want to create, amongst others is needed for the chat-feature. Beside this Messages can be send by the Server, for example to send an updated list of (that are logged in) to all clients.

While trying to understand the whole thing I build a "MessagingService" wich,well i hope this picture saves me some words. (see attachment for the generated sourcecode of MessagingService wich is poorly documented in german language,sorry)


I also read about Delegates, wich I'm not sure about if they are just there to encapsulate everything "remote/async" from Proxys, and maybe they would be even a better way to do this. But I think I'm missing the right idea of then.

I would be glad to recieve some helping tips of what the standard/best appraoch is for this.

By the way: I'm even thinking about using fabrication (even if I'm not sure about modules right now, but this is another topic) and it would be great to have a souluotion which is usable this way

Thx for any help!

Karfau

[puremvc]

I'm not entirely sure you want to start off with Fabrication necessarily, before getting a working understanding of pipes and multicore, the main reason being that pipes and multicore are fully unit tested and provably sound. learning how they work could save you a lot of 'wondering where the problem is in all these layers' questions.

Regardless, multicore is definitely the way you want to go to get maximum reuse of your 'platform' code, making game modules easy to implement.
 
you probably want a message handling  module that handles receiving and sending messages for the platform. That module would probably be pretty lightweight. Actually talking to the service probably happens in a proxy. Its only when multiple proxies need to talk to the same service that you want to push all the knowledge of the service into a delegate. The delegate simply makes calls on behalf of some other actor (proxies in PureMVC) and makes sure the responses flow back to the appropriate caller.

Many people implement delegates based on the Cairngorm style where each actor wanting to talk to a service instantiate their own delegate. That's fine in Cairngorm because they make service calls from Commands, which are short-lived actors. This means that once the command executes, its gone and so is its delegate.

But in PureMVC you may have several proxies (long-lived objects living in a registry; the model)calling a service and waiting for their returns. And those proxies may make many calls to a service throughout their lifetime. So creating a separate delegate instance with its service can be redundant and consume more memory than necessary.

Creating a delegate proxy is one answer that is very compatible with the framework. It is a registerable proxy whois retrieved by other proxies and makes calls on their behalf. The nice thing is you only create one and you can retrieve it from any proxy that needs to make a call. Using the AsyncToken pattern, you can set the name of the proxy and any other contextual info about what that proxy was making the call for on the token which is returned from the call. That token is a dynamic object that supports your adding arbitrary properties.

When the delegate proxy recieves the result or fault, the token tells it who to give the result back to. The calling proxy may also implement IResponder if you'd like and the delegate proxy sets the caller as the responder, in which case the calling proxy needs to pass a reference to itself as a parameter of the call to the delegate proxy.
 
-=Cliff>

[karfau]

Thx for the answer(s).

I'm still not sure if I'm getting everything right. for my better understanding lets split the whole thing into 2 seperate "problems"

1.: Messaging
Maybe the most concrete question is: where do I instantiate the Consumer?
Basically there are two MessagingDestinations for the platform: one to recieve the updated userlist from the server and recieves things like invitations to a game from other clients (and other like tasks, seperated by different subtopics) and the other which is there only for all the chatmessages (of course with different subtopics for each game and one all users).

is this paragraph really all about messaging or does the the messaging part stops at "...lightweight." (thats how far I think understand parts of it )

you probably want a message handling  module that handles receiving and sending messages for the platform. That module would probably be pretty lightweight. Actually talking to the service probably happens in a proxy. Its only when multiple proxies need to talk to the same service that you want to push all the knowledge of the service into a delegate. The delegate simply makes calls on behalf of some other actor (proxies in PureMVC) and makes sure the responses flow back to the appropriate caller.

The problm I see with Messaging is: how can the proxys be updated with the unrequested data? should each relevant proxy subscribe to destination/subtopic and handle incoming messages by itself? Then what about multiple dynamically created Proxys, when for example a new game/chatgroup is opened,when and how to register? If the Proxys are somehow decoupled from the whole messaging, should they be updated by a command which reacts on a special Notification?...wow so manyquestions

I really have no idea of how to use modules, and besides of encapsulating function from the app what are the benefits? Maybe building a "pretty lightweight message handling module" is a good starting point, but I have no idea of how to start. If you still think this would be the best souloution could you give me some hints/links on how to start in a way, that I can use the result in the big app in the end?

2. RemoteObjects
Until now I thaught this (and not mesaging) is where delegates comes into play. maybe I should stay with messaging in this thread and open a new one fo the RO-specific questions. because the plattform is connecting to two RemoteObjects: SessionFacade (scope:session) for everything authentication-specific and PluginFacade (scope: application) for everything about the gameplugins, which should each be used by different proxys the idea of a delegateProxy will help a lot, thx.


Could I make myself (more) clear...

Why I already started to use fabrication (yes without understanding everything beneeth, maybe even without understanding anything beneeth) is that I have to/think I need to/ maybe want to handle with deffered/dynamic instanciation in viewstacks an that fabrication saves me from writing a lot of code for this.

At the moment we have a concept where each game brings its own client- AND serversite code and the only (clientside) connection between platform and specific plugins is starting a game an adding users to it wich were invited (wich leads to load a swf at the appropiate client and initially give it some data to identify and initialize itself over a Function that is defined by a BasePluginApplication)as well as opening a new chatgroup for this gamegroup. so im not sure about what we need modules for gameplugins for.

greetings from germany again,
and thx in advance,
karfau

ps: if this post (or parts of it) doesn't make sence at all, wait for me to read it again when I had some sleep and let me correct it (but you're welcome to give hints on what stays unclear...). cu

[puremvc]

The consumer belongs in a proxy, as well as any producers.

The bebefit of using modules is that you can get maximum code reuse as well as the ability for new modules to easily be written by third parties, contractors or co-workers who need not understand the 'big picture' of how your app works which you may not want to reveal anyway or hand-hold them through until they understand. You can spec a module and the messages it must send and receive (if using pipes) or the interface(s) it must implement or both. From a project management standpoint this can be very beneficial, more so the larger the project.

To understand a little more about multicore and pipes check out the PipeWorks and Modularity demos.

Fabrication is pretty cool, and does a lot of the plumbing for you true. Its just good to understand what's happening under the covers in multicore/pipes to really know what its about. Otherwise it remains 'magic'.

-=Cliff>