Re: RFC: Supporting STK without PDUs

[Denis Kenzior <denkenz@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1863 bytes --]

Hi Waldo,

> I propose to add a set of additional (optional) STK functions that a modem plugin can chose to use/implement instead:
> 
> 	void (*envelope_parsed)(struct ofono_stk *stk,
> 		struct stk_envelope *e,
> 		ofono_stk_envelope_cb_t cb, void *data);
> 	/* if envelope_parsed is non-NULL then stk_send_envelope /
> 	   envelope_queue_run should call envelope_parsed(...) instead of
> 	   stk_pdu_from_envelope(...) + envelope(...)
> 	*/
> 
> 	void (*terminal_response_parsed)(struct ofono_stk *stk,
> 		struct stk_response *rsp,
> 		ofono_stk_generic_cb_t cb, void *data);
> 	/* if terminal_response_parsed is non-NULL then stk_respond()
> 	   should call terminal_response_parsed(...) instead of 
> 	   stk_pdu_from_response(...) + terminal_response(...)
> 	*/
> 
> 	void ofono_stk_proactive_command_parsed_notify(struct ofono_stk *stk,
> 		struct stk_command *command);
> 	/* ofono_stk_proactive_command_parsed_notify is like
> 	   ofono_stk_proactive_command_notify without the call to
> 	   stk_command_new_from_pdu(pdu, length);
> 	*/
> 
> Thoughts?

We have already had a discussion on this one when designing the current
stk modem API.  The bottom line is that oFono tries to keep its core <->
modem interfaces minimal and exposing the entirety of stkutil.h as
official API is definitely too much.

So right now you will need to re-encode into PDU form to support such
modems (or ask the vendor to give the raw pdus)  While this is a bit of
a performance hit, it isn't too bad as the PDUs are always smaller than
256 bytes.

Having said that, such 'pre-parsed' STK APIs are quite common.
Unfortunately they all behave differently, especially when it comes to
handling the more complex commands (e.g. Setup Call, etc)  We have been
kicking around some ideas on how to handle such modems.

Regards,
-Denis