**** BEGIN LOGGING AT Wed Sep 22 02:59:57 2010 Sep 22 13:54:32 hm, which component implements org.ofono.SMSHistory ? and why it has org.ofono prefix? Sep 22 13:56:36 pessi: Probably some external sms history plugin. As to why it has org.ofono prefix, no idea. Must be our UI team missed a memo somewhere Sep 22 14:16:02 in the spec file, they give source URL http://ofono.org ;-) Sep 22 14:17:13 I'm sure they intend it to be upstream... Sep 22 14:25:36 do you have to specifically tell ofono to load external plugins? Sep 22 14:25:45 or does it so automatically? Sep 22 14:25:58 the ofono on n900 refuses to load the smshistory thing Sep 22 14:28:53 hm, no changes in plugin.c since 0.26 Sep 22 14:33:19 it loads them automatically Sep 22 14:33:28 However, the version must be the same Sep 22 14:33:38 And the directory has to be set properly Sep 22 15:01:58 and installing maintainer-mode builds has surpising results ;) Sep 22 15:12:35 denkenz: sent patch allowing multiple -p and -P options Sep 22 15:27:21 what is the point of valid_ussd_string() ? Sep 22 15:27:54 what about separating the mmi stuff into its own Sep 22 15:28:14 ...and allowing applications to send anything as ussd? Sep 22 15:50:01 pessi: Applications can already send anything as USSD, as long as its not the MMI crap Sep 22 15:50:43 pessi: Sending *#31# as a USSD is pointless Sep 22 15:51:50 And valid_ussd_string is taken directly from the 3GPP specs Sep 22 15:58:10 pessi: And jeez, the maintainer mode hacks for plugins have been in there forever ;) Sep 22 16:34:36 denkenz: the 22.090 rules are for network to decide where to route the pUSS-request Sep 22 16:46:29 pessi: So what harm is there in checking this in oFono anyway? Sep 22 16:46:47 And valid_ussd_string also uses rules from 22.030 Sep 22 16:47:36 So far I don't see what you want here Sep 22 17:59:55 denkenz: applications should be able to send anything as ussd Sep 22 18:00:11 and mmi stuff should be handled, err, differently Sep 22 18:00:15 or correctly Sep 22 18:00:15 pessi: Dude, that is not what 22.030 says Sep 22 18:00:22 that is mmi Sep 22 18:00:46 And what application do you have sending USSDs besides the Dialer? Sep 22 18:02:32 anything doing 22.090 section 6 stuff? Sep 22 18:06:33 Then you need to post a use case and a proposal Sep 22 18:06:54 And how this is actually used Sep 22 18:07:03 Since 'addressing is out of scope of this specification' Sep 22 18:09:03 And if this actually refers to STK, then STK can backdoor the SS operations just fine Sep 22 18:09:04 AT&T requirements, user must be able to send any USSD messages from messaging application Sep 22 18:09:55 Yeah, and my iPhone can do this too (not really) Sep 22 18:09:55 and the S60/S40 sms app has an option to do that Sep 22 18:10:38 if i go to there and type "foo" and press send, it is supposed to go to network as ussd Sep 22 18:12:04 Seriously, these requirements are old and pointless Sep 22 18:12:42 The current design is actually doing what its supposed to do, e.g. make writing a Dialer easy Sep 22 18:15:23 sure, we can have InvokeMMI method, but we also need SendUSSD Sep 22 18:16:44 my experience is that as there are billion or so users and almost as many operators, some one is bitten if we don't do old/pointless requirements Sep 22 18:17:44 Yeah, I've seen plenty of these requirements. If we do all of them then we'll be working on this 30 years from now Sep 22 18:17:52 In the end, nobody cares Sep 22 18:18:04 Apple has shown that Sep 22 18:19:49 do you expect any time soon that Apple stops selling phones because they want to do some mud wrestling in court room? Sep 22 18:20:02 I don't want to count on that Sep 22 18:21:02 eh? Sep 22 18:23:31 Please understand that the whole point here is not to continue carrying forward stupid legacies Sep 22 18:23:54 The point is to cut the crap, and make it easy to write apps Sep 22 18:24:21 yeah. cut this mmi crap. Sep 22 18:24:24 or do it properly. Sep 22 18:24:36 And we do it properly according to 22.030 Sep 22 18:24:44 no Sep 22 18:25:00 Ok, tell me how we don't Sep 22 18:33:41 [PATCH] Fix valid_ussd_string() Sep 22 18:34:45 you need to follow the call_in_progress somehow, too. Sep 22 18:41:23 pessi: uh, and where is ussd->call_in_progress coming from? Sep 22 18:42:39 you need to follow the call_in_progress somehow, too. Sep 22 18:43:09 a watch in call atom? Sep 22 18:43:25 sure, but why are you sending it as a PATCH and not as an RFC? Sep 22 18:44:31 And sure, the strlen == 2 case needs to be fixed, but that's a bug, not a poor design choice Sep 22 18:44:39 because my finger get shorter if I type --subject-prefix, and because it already fixes some problems Sep 22 18:46:05 so how do you plan to implement dialer? all input fed to Initiate(), if it returns an undocumented error then call Dial ? Sep 22 18:46:49 Essentially Sep 22 23:37:46 denkez, I am writing the api document for new callhistory adapter-agent style, do I need to put every possible function like functions needed for loading the plugins in those files or the ones needed for communication between the adapter and agent? Sep 22 23:38:59 denkenz, should I send it to ofono.org and mark it Request for comments? Sep 23 00:07:32 raji: DBus API with an RFC header is enough Sep 23 01:40:40 raji: Yes, just send watch you have. It doesn't need to be perfect. We can discuss it on the mailing list. **** ENDING LOGGING AT Thu Sep 23 02:59:58 2010