Implement a service in Gecko that receives OMNA WAP Push notifications and allows receivers to register to be notified when certain MIME types are received. In that case the text content and the uri are passed to the receiver.

Yes, this is basically a mild extension of the MMS protocol. Philipp, who in Taipei should own this? Its pretty high priority to get this off the ground at least to the level where the service dumps messages to logcat so we can stand up the server side in parallel.

Vicamo is familiar with the problem space and actively working on this as part of MMS. I'm tentatively assigning this to him.
Vicamo, feel free to delegate this or some of the MMS work. There's seems to be a lot of stuff that we can share, so you probably know best how to cut up the work. Thanks!

(In reply to Philipp von Weitershausen [:philikon] from comment #3)
> Vicamo is familiar with the problem space and actively working on this as
> part of MMS. I'm tentatively assigning this to him.
>
> Vicamo, feel free to delegate this or some of the MMS work. There's seems to
> be a lot of stuff that we can share, so you probably know best how to cut up
> the work. Thanks!
We've already have a parser for MMS notification receiving with bug 744369. I'm working on creating internal interfaces for Push application registration to complete its function. I think this issue will be covered in bug 744369.

(In reply to Philipp von Weitershausen [:philikon] from comment #14)
> Comment on attachment 625201[details][diff][review]
> Part 0: IDL changes
>
> Review of attachment 625201[details][diff][review]:
> -----------------------------------------------------------------
>
> No need to copy the outdated and overly complicated directory structure
> (src, interfaces, etc.) from other folders. Let's just make a flat directory
> in dom/mms and do dom/mms/nsIMmsService.idl
Please, keep the same structure as dom/sms/ for consistency with other folders. In addition, this is a good habit to have to prevent chaos happening when files get numerous. Now that you have the makefiles to handle this, there is no point in reverting this, really.

(In reply to Philipp von Weitershausen [:philikon] from comment #15)
> > + debug("HAVE_MMS = " + gMmsService.hasSupport());
>
> The lazy getter will instantiate the service at first use. There's no reason
> to do this there and potentially cause a startup slowdown.
Please see my comment in bug 744360 comment #29. I think eventually we'll have to start MmsService on startup just like the SmsService does. I should find a better solution like profile-after-change category, not hard-code in a debug statement. Right?

(In reply to Philipp von Weitershausen [:philikon] from comment #17)
> Beautiful. Though I wonder if his should perhaps not live in dom/system/gonk?
Sorry, but I can't fully understand what you mean?
> > +Cu.import("resource://gre/modules/mms_consts.js");
> > +let MMS = {};
> > +Cu.import("resource://gre/modules/MmsPduHelper.jsm", MMS);
>
> Is there a reason for the separate files here? Can't MmsPduHelper.js include
> the constants?
I'll fix it. BTW, test script for MmsPduHelper is almost done.

(In reply to Philipp von Weitershausen [:philikon] from comment #19)
> Nice work! A few questions below.
>
Thanks. Working with you always make me feel much pleased!
> > + getPdu: function getPdu(httpMethod, uri, callback) {
>
> Does the spec ever specify anything other than "GET" for httpMethod?
>
Yes, there are. According to OMA-TS-MMS_ENC-V1_3-20110913-A[1] section 7:
The MMS PDU is stored to the Data field of the Post, Reply and Push PDUs [WAPWSP]
when using the WSP based stack, and to the Message Body of the POST or Response
HTTP message when using the HTTP based stack.
It follows all MMS PDU must be sent by POST when using HTTP, and all MMS operations involve sending some requests, which are encoded as MMS PDU for certain. There is only one exception: the message fetching from MMS Proxy-Relay. Section 4 in the same document explicitly says message fetching should be done under WSP/HTTP Get.req without a MMS PDU attached. So, in fact, GET method is used by only one case, the very beginning case here. ;)
> @@ +79,5 @@
> > + }
> > +
> > + stream = Cc["@mozilla.org/wap/rilwapbinaryinputstream;1"]
> > + .createInstance(Ci.nsIWapBinaryInputStream);
> > + stream.initFromByteArray(u8array, u8array.length);
>
> What's the purpose of this? I don't quite understand why the Uint8Array
> isn't good enough. This is essentially duplicating the memory consumption.
> Can you explain? Thanks!
>
I've removed them. I found HttpChannel utilizes streams in many case and thought it's the only way to use it. I was wrong.
> @@ +84,5 @@
> > + break;
> > + }
> > + default:
> > + debug("xhr done, but status = " + xhr.status);
> > + break;
>
> No error handling? I guess we're just passing stream = null to the callback
> at this point. Might be nicer to tell the callback why it failed. A common
> callback convention is callback(error, result), so
>
> callback(Components.Exception(...), null);
>
> in case of an error, and
>
> callback(null, result);
>
> when things went fine.
Also fixed.
[1]: http://www.openmobilealliance.org/technical/release_program/docs/CopyrightClick.aspx?pck=MMS&file=V1_3-20110913-A/OMA-TS-MMS_ENC-V1_3-20110913-A.pdf

(In reply to Vicamo Yang [:vicamo] from comment #20)
> (In reply to Philipp von Weitershausen [:philikon] from comment #15)
> > > + debug("HAVE_MMS = " + gMmsService.hasSupport());
> >
> > The lazy getter will instantiate the service at first use. There's no reason
> > to do this there and potentially cause a startup slowdown.
>
> Please see my comment in bug 744360 comment #29. I think eventually we'll
> have to start MmsService on startup just like the SmsService does. I should
> find a better solution like profile-after-change category, not hard-code in
> a debug statement. Right?
Yes, ok. In that case please do that. That would be much cleaner.
(In reply to Vicamo Yang [:vicamo] from comment #21)
> (In reply to Philipp von Weitershausen [:philikon] from comment #17)
> > Beautiful. Though I wonder if his should perhaps not live in dom/system/gonk?
>
> Sorry, but I can't fully understand what you mean?
I was thinking that MmsPduHelper.jsm should perhaps live in dom/system/gonk.

(In reply to Mounir Lamouri (:volkmar) (:mounir) from comment #16)
> Please, keep the same structure as dom/sms/ for consistency with other
> folders. In addition, this is a good habit to have to prevent chaos
> happening when files get numerous. Now that you have the makefiles to handle
> this, there is no point in reverting this, really.
Seems silly to me to create a deep directory structure (that's also no longer used AFAIK) for a prototype implementation that will disappear, but ok.