Skip to contentSkip to conversation

return values of org.ofono.SupplementaryServices.Initiate

DISCUSSION Alexander Kanavin 3 participants 5 messages Oct 5, 2010 – Oct 7, 2010

lore
Share & tools
lore
#0 lore raw

Hi,

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?

string, variant Initiate(string command)

Sends a USSD command string to the network initiating a session. When the request is handled by the appropriate node of the network, the method returns the response or an appropriate error. The network may be awaiting further response from the ME after returning from this method and no new command can be initiated until this one is cancelled or ended.

Possible Errors: [service].Error.Timedout Possible Errors: [service].Error.Canceled

Regards,
Alex

#1 lore raw

Hi Alex,

Quoted 4 lines

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?

Regards

Marcel

#2 lore raw
Quoted 6 lines · ext Marcel Holtmann
Quoted 4 lines

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

#3 lore raw

Hi Alexander,

Quoted 30 lines · Alexander Kanavin
Quoted 6 lines · ext Marcel Holtmann
Quoted 4 lines

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'}))

Quoted 4 lines

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.

This is on my TODO list, but honestly it would take you no more than 2 hours to do this yourself for most of the reply types. All the reply generators are nicely compartmentalized (call-barring.c:
generate_ss_query_reply, call-forwarding.c: cf_ss_control_reply, call-settings.c: generate_cw_ss_query_reply, clip_colp_colr_ss_query_cb)

And you don't really need to handle all the combinations, simply stating that the elements returned in the dictionary were affected by the SS operation is enough.

Quoted 3 lines

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

This patch set predates the launch of oFono as 'oFono'. So far nobody has been attempting to use this API ;)

Regards,
-Denis

#4 lore raw
Quoted 9 lines · ext Denis Kenzior

This is on my TODO list, but honestly it would take you no more than 2 hours to do this yourself for most of the reply types. All the reply generators are nicely compartmentalized (call-barring.c:
generate_ss_query_reply, call-forwarding.c: cf_ss_control_reply, call-settings.c: generate_cw_ss_query_reply, clip_colp_colr_ss_query_cb)

And you don't really need to handle all the combinations, simply stating that the elements returned in the dictionary were affected by the SS operation is enough.

Yeah, I'm actually halfway through that now. I also found a couple of typos in the code. Patches will come soon.

Quoted 2 lines

This patch set predates the launch of oFono as 'oFono'. So far nobody has been attempting to use this API ;)

Except me I guess - I'm now working on a Qt bindings library for oFono.

Alex