Router Decoupling and HTTP Message Processing

[Tobias McNulty]

Hi all,

I started to think through some of the potential implementations for decoupling the route process using HTTP.  Nothing in particular really stuck, so I tried to lay out the problem (and its justification) here:

http://wiki.github.com/rapidsms/rapidsms-core-dev/router-decoupling-and-http-message-processing

I'll try to follow up soon with some potential implementations after staring at the code a little more, but I thought I'd share this in the meantime.  Feel free to tear it apart/add to it as you see fit.  :-)

Cheers,

Tobias
--
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
USA: +1 (919) 951-0052
http://www.caktusgroup.com

[Jonathan Jackson]

Hi Tobias,

Looks like good food for thought.  I wasn't in on the technical discussions of the first Open Mobile Consortium meeting, but I think the goal was partially to create this HTTP separation layer as an interoperability API for RapidSMS.  For those who were there, could someone talk about the initial goal of the SPOMSKY layer and lessons learned from that architecture?

  

-J

--
You received this message because you are subscribed to the Google Groups "rapidsms" group.
To post to this group, send email to rapi...@googlegroups.com.
To unsubscribe from this group, send email to rapidsms+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rapidsms?hl=en.

[Nic Pottier]

I like this direction, especially because it makes the configuration
we probably want to encourage (Kannel running against an SMSC) very
clean. As you pointed out, it also makes testing rather easy, same
goes for development, you are in essence just debugging Django apps.

-Nic

[Tobias McNulty]

I plan to start on this now-ish (i.e., this week); you can track my progress, or lack thereof, at:

http://github.com/tobiasmcnulty/rapidsms-core-dev/commits/route-decouple (nothing there yet)

I think my general approach will be to leave the backends in RapidSMS proper, but break up the monolithic route process into several processes, e.g.:

./manage.py runbackend pygsm

That way the route process is completely optional for kannel, unit testing, etc.

But, given that I'm not /that/ familiar with the code yet, what actually happens may be different.  Any comments/suggestions welcome.  Once I dive in I'll be better prepared to propose a specific solution.

Cheers,

Tobias

--

You received this message because you are subscribed to the Google Groups "rapidsms" group.
To post to this group, send email to rapi...@googlegroups.com.
To unsubscribe from this group, send email to rapidsms+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rapidsms?hl=en.

[Nic Pottier]

Awesome, can't wait Tobias!

From what Evan and Adam have said on the list prior, it sounds like
the biggest gotcha is to make sure you don't get yourself in a
position where you are blocking the HTTP thread for too long. Making
sure that things like outgoing messages (in reply to an incoming
message) are queued instead of sent synchronously should solve the
biggest culprit there.

Looking forward to having things broken up that way.

-Nic

[Kevin Samuel]

I agree, we could use something like Carrot for this kind of queuing.

But isn't a big change for such a close to come version ?

[Tobias McNulty]

On Mon, Aug 16, 2010 at 4:48 AM, Kevin Samuel <info.k...@googlemail.com> wrote:

I agree, we could use something like Carrot for this kind of queuing.

But isn't a big change for such a close to come version ?

Probably; I don't think any decision has been made about when this is going in, nor do I presume that it'll go in with the next release.  Just thinking about it wasn't getting me anywhere, however, and the need is definitely there, so I decided to start writing code.  I'll keep my branch up to date (hopefully it won't be too painful).

Tobias