Created attachment 212747 [details] [review]
Add mmsc

Add mmsc information and update DTD.

I notice that in serviceprovider.xml, many apns whose types are 'internet' can also be mms apns. So I didn't put those mmsc information under <usage type="mms">

Created attachment 215836 [details] [review]
Add MMS

Add mms information.
I use the format 

<apn value="wap.cingular">
	<plan type="postpaid"/>
	<usage type="internet"/>
	<usage type="mms">
		<mmsc>http://mmsc.cingular.com</mmsc>
                <mmsproxy>wireless.cingular.com</mmsproxy>
                <mmsport>80</mmsport>
	</usage>
	<name>MEdia Net (phones)</name>
</apn>

I didn't add it as attribute as Dan suggested in [1] because I found in your 
database you didn't add some many attributes in any element.

Suggestions are welcome~~

thanks

[1]https://bugzilla.mozilla.org/show_bug.cgi?id=729440#c31

Yeah, that format looks good, but we also need the DTD for this so we're sure it validates; you can run 'make check' in the git checkout to see if it validates.

The downside of putting these elements under <usage> is that we can't validate the children fully, since I don't think we can make the DTD specify at least one MMSC element when type="mms".  It seems pretty pointless to have a <usage type="mms"> without at least an MMSC, though I know some existing entries are done that way.

That said, I don't know DTD very well, so maybe there's a way to do it?  Also, 'make check' fails because the DTD expects all the "usage" elements to be ordered together.  That's kinda stupid too, but I couldn't find a way to make the element ordering be ignored in 5 minutes of googling.  Perhaps somebody can elighten me?  I did move all the new <usage> stuff up and that fixes the warnings, patch attached.

Also, I'd be happy to include the XML -> JSON script in MBPD git to generate the JSON as part of the normal install process.

Created attachment 215856 [details] [review]
Fix DTD and validation

Hi, Dan
Thanks for the correction, sorry I didn't notice I can run "make check" in the first place.Next time I'll keep this in mind.

Sorry I didn't know DTD well either, but if you or other developers have some suggestions in mind you could post it here, I'll update my patch accordingly.

For the XML -> JSON, I use a webpage http://jsontoxml.utilities-online.info/, I'll try if I can provide a script here too.

Thanks for the correction and comments. :)

What's the point in splitting MMS proxy information into host and port parts, and not doing the same for MMSC? If you follow the same pattern and be consistent, you will end up with something like this:

  <mmscprotocol>http</mmscprotocol>
  <mmschost>mmsc.cingular.com</mmschost>
  <mmscport>80</mmscport>
  <mmsproxyhost>wireless.cingular.com</mmsproxyhost>
  <mmsproxyportport>80</mmsproxyport>

I think this is horrible. Instead, I suggest to collapse that into two elements:

  <mmsc>http://mmsc.cingular.com</mmsc>
  <mmsproxy>wireless.cingular.com:80</mmsproxy>

In addition to saving space and reducing number of XML elements to parse, it  also makes it easier to integrate these changes into oFono. oFono context has "MessageProxy" and "MessageCenter" properties which would nicely map to these two xml elements. What do you think?

Created attachment 261431 [details] [review]
Yet another MMS patch

Created attachment 261435 [details] [review]
One more MMS patch

And another (more compact) way to do it, this one looking like this:

	<apn value="mms">
		<usage type="mms"/>
		<name>dna MMS</name>
		<username>dna</username>
		<password>mms</password>
		<mmsc>http://mmsc.dnafinland.fi</mmsc>
		<mmsproxy>10.1.1.2:8080</mmsproxy>
	</apn>

Since this bug has been inactive for more than a year, I have to assume that it's very unlikely that any of these patches will ever get applied and therefore we will need to fork and maintain our own version of this stuff. Too bad, I would very much like to avoid that...

I agree with with the more compact format you have proposed, and have applied your patch.  Thanks!

Slava (and yhuang!), if you have any more patches, please send them along, and keep pestering us until they get applied.  Sorry for any delays, we'd love to keep things moving.