On 05.10.2010 15:06, ext Marcel Holtmann wrote:
>> doc/supplementaryservices-api.txt says nothing about return values of
>> SupplementeryServices.Initiate method (or that the method can take SS
>> requests in addition to USSD). Can the API designer/implementer fix this
>> please?
>
> why don't you just send a patch for it if it is unclear?

If it was a small update I would just send a patch. But a typical return 
value for example is:

(u'CallBarring',
  (u'interrogation',
   u'AllBarringServices',
   {u'DataAllIncoming': u'disabled',
    u'DataAllOutgoing': u'disabled',
    u'DataIncomingWhenRoaming': u'disabled',
    u'DataInternationalOutgoing': u'disabled',
    u'DataInternationalOutgoingExceptHome': u'disabled',
    u'FaxAllIncoming': u'disabled',
    u'FaxAllOutgoing': u'disabled',
    u'FaxIncomingWhenRoaming': u'disabled',
    u'FaxInternationalOutgoing': u'disabled',
    u'FaxInternationalOutgoingExceptHome': u'disabled',
    u'VoiceAllIncoming': u'disabled',
    u'VoiceAllOutgoing': u'disabled',
    u'VoiceIncomingWhenRoaming': u'disabled',
    u'VoiceInternationalOutgoing': u'disabled',
    u'VoiceInternationalOutgoingExceptHome': u'disabled'}))

Now multiply this by all possible combinations of supplementary services, 
supplementary service operations and basic services. Remember the second 
argument is a variant, so it's entirely freeform. So I sought to ask about 
this on the list first.

A patch(set) that changes the API shouldn't be accepted in the first place 
if it doesn't properly update the documentation.

Regards,
Alex