--
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
--
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.
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
But isn't a big change for such a close to come version ?
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 ?