On Wed, 2010-06-16 at 17:20 +0100, Neil Williams wrote: > On Wed, 02 Jun 2010 01:08:57 -0700 > Dan Williams <[email protected]> wrote: > > > On Tue, 2010-05-25 at 10:37 +0100, Neil Williams wrote: > > > On Mon, 24 May 2010 16:46:34 -0700 > > > Dan Williams <[email protected]> wrote: > > > > - When two <dtmf> are listed, what's the difference between the two? Do > > > > both do the same thing? Or are they different? > > > > > > The same "networkID" can have differing implementations from which the > > > user needs to select according to local requirements like tariff or > > > locality or handset. Our UI offers a default and then allows the user to > > > choose from the alternatives. > > > > Is it useful to tag those different implementations with a name? We > > could add a name to each of the items that need it, though it can't be a > > property, it'd have to be a sub-element so that it could be localized. > > Each definition is more of a fallback than a discrete alternative. We > don't have a reliable way of mapping one alternative to one particular > description. Current theory is that service providers themselves > "adopt" new details when taking over smaller networks etc. and then fold > those into the main network such that whichever method works gets > through to the same network space. So some items will be legacy and > some will be ongoing alternatives which providers maintain for their > own reasons (and could drop or switch at any time). We really cannot > tell from this end. Where both alternatives work in our tests, there > appears to be no way to distinguish one alternative from another, > except by changes which would be inherent in the type of interface. > > There may have been a name tag for some alternatives but there is also > no guarantee that providers will continue using the same name on the > handset, leading to confusion. > > All we have been able to establish is that certain alternatives do > appear to be a sane default and those are listed first. > > > > > - For the SMS balance check, when two <sms> items are listed, what's the > > > > different between the two? > > > > > > Handset / regional / tariff based differentiation. The user configures > > > which of the available methods to use, the choice is then stored in > > > the application. > > > > Again, might make sense to have <name> and <desc> subelements to give > > users some help here too. > > If we could know that the name or desc would be persistent then that > would be useful. That just doesn't appear to be a reliable assumption > and is outside user control, sadly. > > > That would mean changing the format a bit though to something more like: > > > > <voicemail dtmf="901"> > > <name xml:lang="de">asdfadfadf</name> > > <desc xml:lang="de">Blah Blah</desc> > > </voicemail> > > > > and the same for the rest of the items. Or replace the "dtmf" attribute > > with an element inside voicemail perhaps. Either way. Maybe we don't > > actually need name/description for some of these? The issue is that if > > we go with the format you're suggesting, it's really hard to add > > localized name or description later without breaking the DTD. > > From this end, it looks more like adding names or descriptions (and > then translating them) is more likely to be misleading and error-prone, > causing more work for everyone. > > > I'd also like to see comments in the DTD if we can stuff them in about > > what each of the new fields is, like you've described them here. That > > makes the DTD more of a "specification". Or if that's not the right way > > to do it, at least comment about them at the top of the XML file. > > Comments added to the DTD. > > > > No problem. Further updates may follow as more devices get out to real > > > users. Network methods can be impossible to test without real access to > > > the network itself. > > > > Completely understood. Think you'd be able to respin the patch with the > > suggested changes? > > I'm attaching a revised patch with the DTD comments to replace the > first one we sent.
Pushed, thanks! Dan _______________________________________________ networkmanager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
