A-IM architecture decisions... (Question for Andrew)

I had a thought about the current A-IM architecture. It seems that one issue that the system is having right now is keeping the server, asterisk and client all in sync with each other. Currently, the server itself is taking care of overriding the user status when the user is on or off a call, and there is a lot book keeping associated with that.

I was wondering if an alternative approach may prove to be more straight forward, and wanted to run it past you to see if I’'m on base:

What if the server was responsible only for sending state notification messages to spark, and spark was responsible for changing the user’'s status in response to those notification messages? It seems that this would give the user more control over things (and would at least give the user an ‘‘out’’ if the event mechanism fails to detect a hangup event). I guess this might have some negative implications if you had a user using a non-spark client, though…

Is that the reason for the current architecture?

Thanks,

  • K

Message was edited by: andrew

We have discussed taking this approach.

It would allow for the added benefit of removing wildfire dependencies. The only portion that is very dependent on wildfire right now is the session management.

The biggest reason why we haven’‘t taken this approach at this point is that most clients do not support asterisk-im at this point, and we would like everyone’'s session status to change regardless of what client they use.

We will probably revisit this issue with 2.0. 2.0 will probably include many major changes such as using pub-sub.

OK - I was thinking along those lines as well. I’‘m actually thinking about doing some work in the asterisk-im arena. I’'d like to add an ehanced feature set, and was wondering what you thought…

Specifically, I’'m looking into call control via a spark plugin. The idea would be to use the asterisk management console to initiate call transfers, transferse to voicemail, putting the current call on hold, etc…

My current thinking on this is to create a spark plugin that tracks current call information (based on a-im events similar to what I described in the original post). This information could be used as a key in requests made from the plugin back to the a-im server, which would look up and execute the appropriate asterisk-manager request.

I’‘m a little bit bummed that the spark call handling functionality isn’'t implemented as an open-source plugin (the ideal place to put a hold button, for example, would be in the ‘‘current call’’ dialog), but no biggie (although it might be nice if we could eventually turn off the built in call handling behavior in spark and rely on a plugin instead…)

Any comments on this idea?

  • K

hey,

Did you see the private message I sent you regarding this?