On Mar 11, 2005, at 11:33, Søren Hansen wrote:

tor, 10 03 2005 kl. 20:28 +0300, skrev Andrew Wingorodov:
MM7 support is coming soon.
Whether I can be connected to work?
It is very necessary MM7.
I Suggest to make on CGI - simply and quickly
That do you think ?

MM7 is in the works. Well, it's on my todo list. I haven't actually
gotten started on it, but I've figured out how to do it, and it should
be fairly straightforward.
If anyone else feels like doing it, take a peek at (from memory)
mmsc/mmsproxy.c in sendmms_proxy. There's a check to see if there's a
body, followed by a call to mms_frombinary. If that returns a NULL
pointer, an error is returned to the sender.
I'm planning on implementing MM7 by checking if mms_frombinary returns
NULL and if it does, I'll call a newly created function called
mms_fromsoap which does the same thing as mms_frombinary and
mms_frommime only extracting the message from the soap package.
The big hurdle, obviously, is coding mms_fromsoap. If anyone is in the
mood, feel free to take a stab at it. I probably won't have time to look
at it for a week or so.



I tend to disagree with this approach. mmsproxy should remain for the mm1 interface alone. 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).


The key reason for the above is: Lets keep each interface simple enough, otherwise we'll increase the management overhead. Also, the SOAP encoding should be kept away from the native (binary) coding stuff as much as possible.

Lets exhaust the discussion here or offline before you make any changes.

P.

--
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

Reply via email to