Re: Router vs HttpRouter

[Nic Pottier]

On Thu, Mar 31, 2011 at 6:07 PM, Tobias McNulty <tob...@caktusgroup.com> wrote:
>> I recommend you use this backend:
>> https://github.com/mwana/mwana/blob/develop/mwana/backends/kannel.py

So out of curiosity, if you are going against Kannel, why do you think
the default RapidSMS backend is better?

The HTTP-Router backend is far, far simpler, you get nice message
Models for free, and it is better tested than the default.

I'm not actually really trying to make a solid argument FOR it, it
doesn't really matter to me, but rather am just curious as to your
reasons for recommending something apart from it.

At this point is has quite a bit of real world experience in the field
going against Kannel.

-Nic

[Cory Zue]

On Thu, Mar 31, 2011 at 8:33 PM, Nic Pottier <nicpo...@gmail.com> wrote:

On Thu, Mar 31, 2011 at 6:07 PM, Tobias McNulty <tob...@caktusgroup.com> wrote:
>> I recommend you use this backend:
>> https://github.com/mwana/mwana/blob/develop/mwana/backends/kannel.py

So out of curiosity, if you are going against Kannel, why do you think
the default RapidSMS backend is better?

The HTTP-Router backend is far, far simpler, you get nice message
Models for free, and it is better tested than the default.

I'm not actually really trying to make a solid argument FOR it, it
doesn't really matter to me, but rather am just curious as to your
reasons for recommending something apart from it.

I recently evaluated both these options and ended up choosing (at least for the time being) the router proper + tobias's kannel backend. My primary reason was that it makes me a little uncomfortable that you've essentially reimplemented the entire functionality of the router process in a second class. One can imagine that as the rapidsms project progresses these implementations might diverge considerably, and for the time being I'd rather be on the rapidsms proper architecture. The rapidsms router and kannel backend have also been field tested extensively, and I think both options are fine, I just don't really see a reason _for_ the HttpRouter to coexist with the HTTP backends already built into rapidsms.

[Tobias McNulty]

On Thu, Mar 31, 2011 at 2:33 PM, Nic Pottier <nicpo...@gmail.com> wrote:

On Thu, Mar 31, 2011 at 6:07 PM, Tobias McNulty <tob...@caktusgroup.com> wrote:
>> I recommend you use this backend:
>> https://github.com/mwana/mwana/blob/develop/mwana/backends/kannel.py

So out of curiosity, if you are going against Kannel, why do you think
the default RapidSMS backend is better? 

 

The HTTP-Router backend is far, far simpler, you get nice message
Models for free, and it is better tested than the default.

I'm not actually really trying to make a solid argument FOR it, it
doesn't really matter to me, but rather am just curious as to your
reasons for recommending something apart from it.

For the same reasons I objected to it before (namely, that starting threads in the HTTP request/response cycle seems no better to me than the built-in route process).

 

At this point is has quite a bit of real world experience in the field
going against Kannel.

Interested to hear it if there is, but that's a different argument.  If someone wants to use Kannel with RapidSMS, they might as well use the supported way of doing so (the built-in route process).  Don't get me wrong, though, I still hate the route process :-).

Back to Kannel, there's a lot that it does better than any of the backends in RapidSMS, and I have yet to see anyone present any tangible evidence to suggest otherwise.

Tobias

--
Tobias McNulty, Managing Partner

Caktus Consulting Group, LLC
http://www.caktusgroup.com

[Nic Pottier]

I'll tag team both of ya, not meaning to start a big debate here, was
more just gathering opinions. But I'll respond quickly and then leave
it at that.

Cory:

> My primary reason was that it makes me a little uncomfortable that you've
> essentially reimplemented the entire functionality of the router process in
> a second class. One can imagine that as the rapidsms project progresses these
> implementations might diverge considerably, and for the time being I'd rather be
> on the rapidsms proper architecture.

Ya, that's a valid concern, and certainly something that gave me
pause. Sadly I couldn't figure out any super clean way of abstracting
that out. I'd say that particular interface has been pretty darn
stable though, it has been the same in the last two major versions as
far as I know. But ya, I hear you.

Tobias:

> For the same reasons I objected to it before (namely, that starting threads
> in the HTTP request/response cycle seems no better to me than the built-in
> route process).

Ya, this was a really big one for me actually. I resisted it, but
then David was using it with good luck and I took a look again and
gave it a try and have never looked back. The sending all takes place
in separate threads, but yes, they are _started_ in the HTTP thread.

I just like that it's one less thing to worry about. When deploying I
set up gunicorn via supervisor for my one Django process and that's
it, done. Easy to monitor, easy to restart, very predictable.

It is also much more predictable to test again, since you turn off all
the threading nonsense for tests (and have things queued in the db)
but are still testing the entire app handling process.

> Interested to hear it if there is, but that's a different argument.

Just as a datapoint, we have three different installs using it now, a
fourth in about a week. We are pushing a decent number of messages,
but probably nowhere near David.

> Back to Kannel, there's a lot that it does better than any of the backends
> in RapidSMS, and I have yet to see anyone present any tangible evidence to
> suggest otherwise.

Totally agree with you there. The biggest pain is the initial
configuration, but once that is done it seems rock solid and is super
flexible.

-Nic

[Tobias McNulty]

On Thu, Mar 31, 2011 at 4:34 PM, Nic Pottier <nicpo...@gmail.com> wrote:

> Interested to hear it if there is, but that's a different argument.

Just as a datapoint, we have three different installs using it now, a
fourth in about a week.  We are pushing a decent number of messages,
but probably nowhere near David.

Confused - my point was about Kannel, which I thought you were arguing against. 

[Nic Pottier]

On Thu, Mar 31, 2011 at 10:37 PM, Tobias McNulty <tob...@caktusgroup.com> wrote:
>> Just as a datapoint, we have three different installs using it now, a
>> fourth in about a week.  We are pushing a decent number of messages,
>> but probably nowhere near David.
>
> Confused - my point was about Kannel, which I thought you were arguing
> against.

Rereading what I said I could see why, about as clear as mud:

"At this point is has quite a bit of real world experience in the field
going against Kannel."

What I meant was rapidsms-httprouter has quite a bit of real world
experience USING Kannel to deliver its messages. Not that we have
anything against Kannel, we LOVE kannel and that's why I like
rapidsms-httprouter because they mate so easily.

-Nic

[Tobias McNulty]

Haha, phew.  Makes more sense now.  I was about to find a stick and hit you with it.  :-)

Tobias