On Mar 11, 2005, at 12:48, Søren Hansen wrote:
fre, 11 03 2005 kl. 12:28 +0300, skrev Paul Bagyenda:I tend to disagree with this approach. mmsproxy should remain for the
mm1 interface alone.
Ok. I see your point.
You should build a different interface which
receives SOAP or EAIF (I think both should be done right off and
distinguished by called URL). It then does the VAS user authentication,
and creates an MMS message which it queues to the global queue.
Similarly, global sender should be updated to route messages to
SOAP/EAIF recipients based on short number (or something), if the
recipient is not local etc. Finally we would need config directives for
VAS providers: name, user/pass (required for auth), short code (or
similar), flags, URL (which we use for sending incoming to them).
Right.
Lets exhaust the discussion here or offline before you make any changes.
Sure. Good thing I hadn't started yet. :-)
So, you think I should create a whole new binary for this, or should we
perhaps just use a different URL for it and keep it in mmsproxy, but
separate from the mm1 stuff? I'm not sure what I think about this.. Both
have benifits.
It can be part of mmsproxy but it should be a separate function space. So you would probably have a whole new lib file for EAIF and SOAP decoding encoding, and a different URL handler.
-- Søren Hansen <[EMAIL PROTECTED]> _______________________________________________ Users mailing list Users@mbuni.org http://mbuni.org/mailman/listinfo/users_mbuni.org
_______________________________________________ Users mailing list Users@mbuni.org http://mbuni.org/mailman/listinfo/users_mbuni.org
