**** BEGIN LOGGING AT Tue Sep 14 02:59:57 2010 Sep 14 17:33:02 denkenz: can I expain the purpose the following code Sep 14 17:33:16 sure Sep 14 17:34:25 Incase the conversion didn't go well, we will have null string and status = USER_ACTION_REQUIRED or something else Sep 14 17:35:07 providing a null string asking for user action will be weird Sep 14 17:36:32 > + if (!utf8_str) { utf8_str = ""; status = OFONO_USSD_STATUS_NOTIFY; Sep 14 17:39:05 Why would conversion not go well? Sep 14 17:39:44 Besides, setting user action with a null string is safer than not telling the UI that the network is expecting something Sep 14 17:40:20 denkenz: any opinion to my sms-agent pathces Sep 14 17:40:38 ok Sep 14 17:41:12 akiniemi: I'm still totally against the mimetype idea Sep 14 17:43:09 In the end it is even less flexible than integer ports Sep 14 17:44:35 denkenz: that is why I was originally proposing a "application/x-sms-agent;port=12345" construct Sep 14 17:44:44 denkenz: but holtmann shot it down Sep 14 17:45:26 See, in all honesty I'd rather see something like: RegisterAgent() that handles text, vcard and vcal Sep 14 17:45:47 And a separate agent / signal that parses WAP pushes and sends the XML Sep 14 17:46:03 And stop at that until more requirements come Sep 14 17:46:16 denkenz: so you want to wake up the vcard agent every time there's an SMS? Sep 14 17:46:26 I just want 1 agent Sep 14 17:47:18 I want something simple that satisfies the immediate requirements, not try to design something with no clear usecases in mind Sep 14 17:48:03 I'm not seeing how my patch doesn't already give you this Sep 14 17:48:31 modulo accepting a "text/*", which is easy enough to add Sep 14 17:49:41 Your API screams complicated Sep 14 17:50:52 Not quite as loud as ProposeScan() or whatever it was... ;) Sep 14 17:51:41 Shrug, not my fault the hw is stupid Sep 14 17:53:20 No, you were trying to be clever, when all anyone ever wanted was a single method that returns available networks. That's it. Now it is there, thanks for that. Sep 14 17:54:12 Anyway, what exactly do you think is complicated in the API? Sep 14 17:57:28 Not really what 'anyone ever wanted' Sep 14 17:57:55 And I've already had this conversation with you 15 times Sep 14 17:58:03 I don't want multiple agents, I don't want mimetypes Sep 14 17:58:20 I just want a signal / method for the VCard, VCal and the text message Sep 14 17:59:20 And I assume in the sending side you want a SendVCard() and a SednVCal()? Sep 14 17:59:35 Yep Sep 14 18:00:37 And not a SendDatagram(), with type? Sep 14 18:00:58 So far I don't see an actual usecase Sep 14 18:01:23 When we have one, then we can discuss whether SendDatagram is required, or another plugin with a custom API Sep 14 18:01:48 I sent two use cases on the list Sep 14 18:02:49 No, you sent two bullet points Sep 14 18:03:07 use case needs a bit more meat Sep 14 18:03:14 Oh please Sep 14 18:05:29 Why is it so hard to start small? Sep 14 18:06:24 Just build one block at a time, keep it simple and see what is actually needed Sep 14 18:12:45 You seem to forget this isn't the first time I do this stuff Sep 14 18:13:28 Anyway, there is a TODO item even about supporting rich text, or text/html Sep 14 18:19:17 And you seem to forget that it isn't my first time either ;) Sep 14 18:20:39 All I'm saying is, start small, build up Sep 14 18:20:58 So so far you're suggesting Register() for text/vcard/vcal, RegisterPush() for push, and mirror those for methods Sep 14 18:21:48 More or less Sep 14 18:22:01 There's no need to send pushes Sep 14 18:30:16 And we forget about supporting rich text, right? Sep 14 18:32:18 Rich text is EMS Sep 14 18:32:32 And that is actually a whole can of worms Sep 14 18:32:43 Since EMS can contain text attributes, sounds, pictures Sep 14 18:32:52 so 'Rich Text' is a bit simplistic Sep 14 18:33:44 If we are to do it right, we'd need a seriously good HTML parser, or a custom XML file format Sep 14 18:34:01 Why bother, nobody supports it anyway... Sep 14 18:35:45 And your thoughts on file-based agent registration? Sep 14 18:36:44 SonyE devices support it just fine Sep 14 18:36:59 file-based? You mean some sort of D-Bus activation trickery? Sep 14 18:37:10 Yup Sep 14 18:37:41 I'd avoid it like the plague myself Sep 14 18:38:05 Especially since you have system vs session bus issues Sep 14 18:38:25 What do you mean? Sep 14 18:38:55 Naturally there needs to be a matching .service file Sep 14 18:39:28 This allows global agents, too Sep 14 18:40:29 That is, an agent that listens to any SMSs (using any modem) Sep 14 18:40:39 Yeah, but how do you propose a system daemon running as root to activate apps in the user session? Sep 14 18:41:25 What do you mean? The agents are on system bus when they Register(), too. Sep 14 18:41:48 AFAIK, system bus does not support activation Sep 14 18:41:52 Unless its been hacked Sep 14 18:43:06 However, global agents are certainly something we need to figure out Sep 14 18:43:43 e.g. 1 agent registered to multiple modems Sep 14 18:44:07 However, it is quite complicated to solve in the current ofono structure Sep 14 18:45:01 And the API does not expose the originating modem Sep 14 18:48:48 denkenz: the .service file includes a 'User', which is the uid to use when activating Sep 14 18:49:46 I think not exposing the originating modem is only a problem for replies Sep 14 18:52:12 akiniemi: I can't think of any situation where the originating modem is needed off the top of my head Sep 14 18:52:28 But it would suck if it were needed Sep 14 18:57:05 Well, you need to be able to pick the right modem to send the reply using the correct IMSI Sep 14 18:57:44 Then that's a bit of a problem Sep 14 18:59:01 Just add a ReplyTo key with object path for the atom? Sep 14 18:59:44 See, that is a small issue compared to how you manage shared agents across modems Sep 14 19:00:48 You need reference counting (e.g. to send Release() only when last modem exits), shared agent store Sep 14 19:00:50 etc Sep 14 19:02:37 I was thinking each atom reads the static agent config files, and remembers them Sep 14 19:03:05 And sending Release() is no problem, since likely these agents will exit anyway after processing a message Sep 14 19:03:27 (The whole point of D-Bus activation) Sep 14 19:03:36 See, but then you have race conditions Sep 14 19:03:48 e.g. and SMS arrives on one modem, and the other modem is removed at the same time Sep 14 19:04:41 The agent can simply ignore the Release() Sep 14 19:05:29 Sounds nasty and complicated Sep 14 19:05:41 Release() doesn't mean "exit, now", the agent can check to see if it is processing a message and wait until it finishes Sep 14 19:06:12 Trouble is, Release() also means you need to re-register to a modem Sep 14 19:06:37 For example, in the case of STK, Release() gets called for several reasons Sep 14 19:06:53 SMS != STK Sep 14 19:07:02 Sure, but some of those reasons apply to SMS as well Sep 14 19:07:11 e.g. SMS Agent returning an Error from a method call Sep 14 19:09:18 SMS agent should never return an error Sep 14 19:09:42 I agree, but we're a system daemon, we don't rely on that Sep 14 19:10:14 should Release then have the modem path as argument? Sep 14 19:10:41 I don't know Sep 14 19:11:06 It sounds like your dbus activation idea is going in a slightly different direction Sep 14 19:11:29 So perhaps you need to present a use case, maybe using Agents is not necessarily the right thing Sep 14 19:12:41 Not the use case cop out again... Sep 14 19:12:58 Seriously, I don't know what you want to do Sep 14 19:13:06 If you want some app called when a VCard arrives Sep 14 19:13:15 We want not to run an agent all the time, when you're likely to only receive a push, what, one a year? Sep 14 19:13:15 You can make a plugin with D-Bus activation Sep 14 19:14:04 What does "a plugin with D-Bus activation" really mean? Sep 14 19:14:16 e.g. Sep 14 19:14:16 That we duplicate most of the agent code in a plugin? Sep 14 19:14:49 Register to VCard push, whenever one arrives read some /etc/ofono file and call a method described in that file Sep 14 19:14:54 No need for Agents at all Sep 14 19:16:32 How about the SMS atom doing that when it is about to dispatch to agents anyway? Sep 14 19:18:55 I'm lost now, you want d-bus activated agents that bypass RegisterAgent? Sep 14 19:19:32 Sure Sep 14 19:19:49 Read the configs of static agents when an atom is created Sep 14 19:20:14 Why bother? Just write a call history plugin and be done with it Sep 14 19:21:03 Remember, the idea is to keep it simple Sep 14 19:21:20 not try to enable every esoteric way of using the system imaginable Sep 14 19:21:51 Not every one, no. Just the ones we're using *today*. Sep 14 19:24:25 Everything has to weighted and evaluted. Not everything someone is using 'today' is necessarily a good idea Sep 14 19:30:53 Today's usage has to count, too. Completely ignoring what current telephony stacks have available is silly. It screams of NIH. Sep 14 19:32:45 BS, that argument is over used Sep 14 19:33:30 Which argument? Sep 14 19:33:32 current telephony stacks also push everything out to the UI, or implement features which are not used by anyone anymore Sep 14 19:33:38 It does not mean we should do the same Sep 14 19:35:10 Where have I suggested pushing anything out to the UI? Sep 14 19:35:50 'Completey ignoring what current telephony stacks have available is silly. It screams of NIH.' Sep 14 19:36:24 Huh? Sep 14 19:37:28 In the end, we are completely ignoring many aspects of what other telephony stacks have available Sep 14 19:37:42 Like phonebook access, SMS storage on SIM, SIM full notifications, etc Sep 14 19:38:20 And so far we're doing just fine Sep 14 19:38:52 BS, you've yet to ship a product, or type approve it, or have a carrier approve it, so you don't know. Sep 14 19:40:31 There is a lot of stuff that needs to be done, and at this rate, it won't get done any time soon. Sep 14 19:41:48 Then please accept the project goals and work within those boundaries Sep 14 19:42:01 Hacking shit until it works is not our way Sep 14 19:44:37 Apparently stonewalling with use-cases and "just put it in a plugin" then is? Sep 14 19:45:46 And what are you talking about anyway? Sep 14 19:48:44 Look, the core is designed to be ultra small Sep 14 19:48:56 just do a loc count on how small the core actually is Sep 14 19:49:03 I want to keep it that way Sep 14 19:49:20 Hence the rule of thumb is, if there's more than 1 way to do something in the core, you're doing it wrong Sep 14 19:49:56 In the end, all of src/dst port stuff needs to be handled by plugins Sep 14 19:50:06 Unless we design an API that everyone is happy with Sep 14 19:50:10 So far this hasn't happened Sep 14 19:50:47 So, why don't you just write the src/dst port dispatcher framework first Sep 14 19:51:03 The internal one Sep 14 19:51:17 And then we can go from there Sep 14 19:51:35 sms.c has that already Sep 14 19:52:01 Or are you talking about the history plugin API? Sep 14 19:52:30 No, I'm talking about __ofono_sms_register_port_handler() Sep 14 19:52:44 And the appropriate plugin infrastructure, like history or nettime Sep 14 19:53:33 And btw, I'm really sorry you view it as 'stonewalling' Sep 14 19:53:50 In fact, I viewed it the same way about 5 years ago Sep 14 19:54:07 But along the way I changed my mind Sep 14 19:54:33 So you want SMS ports as a separate plugin API from history? Sep 14 19:54:55 SMS ports are not recorded in history today Sep 14 19:55:18 But they should be separate regardless Sep 14 19:58:17 The idea here is that someone like AT&T can come in, write a simple src/dst port plugin that reads whatever custom VVM format they have and exposes it over D-Bus Sep 14 19:58:39 Same goes for VCards, VCals, Carrier Logos, whatever else Sep 14 19:59:05 And these plugins can be out-of-tree if need be Sep 14 19:59:13 Why can't this then be a simple extension to history? Sep 14 19:59:23 Like __ofono_history_sms_datagram_received() Sep 14 20:00:14 And sure, in that sense plugins are great. We can hack shit until it works, right? Sep 14 20:00:33 I would personally see this stuff in the core, but heck either way works. Sep 14 20:01:10 Sometimes there needs to be flexibility for people to hack shit until it works without polluting the project Sep 14 20:01:25 So yes, partly there is that intent Sep 14 20:01:39 However, largely it is a simple 'one way of doing something' part Sep 14 20:02:57 It can be done via history as well Sep 14 20:03:23 My thinking so far is that VCard/VCals should not be history tracked, but I'm open to suggestions Sep 14 20:08:16 Shouldn't that be up to the history plugin? I mean, storing received vCards is useful, and the UI will likely have that option. Sep 14 20:09:31 If that is a usecase the UI wants to do, then its perfectly OK with me Sep 14 20:09:47 This could be a completely new API with __ofono_sms_register_handler() or something that could dispatch all types of messages, maybe even a struct *sms... Sep 14 20:10:53 To me it seemed storing arbitrary bytes in history was not a good idea, or having to filter the src/dst pairs the UI might actually be interested in Sep 14 20:11:42 However, the intent of history is to give 'raw' access, so I'm perfectly fine exposing that info Sep 14 20:12:38 Ok, so I will make my smsagent a plugin using the history API, and extend history so that it'll provide all the goods necessary Sep 14 20:13:58 You want that in-tree? It'll have nasty MIME types and stuff. ;) Sep 14 20:15:04 give me the src/dst dispatcher first ;) Sep 14 20:17:35 Um, you mean __ofono_history_sms_datagram_received() or a new API? Sep 14 20:18:55 I'd like to see a proper src/dst port register & handler cb Sep 14 20:19:34 The history piece is probably not going to be interested in anything besides vcard or vcal Sep 14 20:41:48 denkenz: are you free now to discuss about the one review comment in USSD Sep 14 20:45:50 sure Sep 14 20:47:34 about the USER action requriedreview comment Sep 14 20:49:28 Once the ussd request is initiated, there can be dialgoes between user and network Sep 14 20:50:20 Incase if the USSD data download is enabled, then we might need to send the dialogues as download to SIM Sep 14 20:51:08 So when does Send USSD send a terminal response? Sep 14 20:51:10 if its not enabled, then the ME doesn't need to send the dialoges, ME just need to inform when the USSD transaction is completed Sep 14 20:51:47 Terminal response is sent after the release complete messag from netwokr or user cancellation Sep 14 20:52:57 First if loop in the ofono_ussd_notify takes care of calling ussd_request_finish for Release complete case and all other error cases Sep 14 20:53:46 Whereas for User cancellation case, it is handled in the ussd_cancel_callback Sep 14 20:54:29 Ok, so I don't see how USSD download works here Sep 14 20:55:13 If we receive a USSD Download, then the SIM would have to initiate another Send USSD Sep 14 20:55:32 nope Sep 14 20:55:51 Just to keep the SAT informed of the complete dialogues Sep 14 20:57:22 What I'm saying is, Send SS -> OK, network responds with User Action with DCS == USSD Data Download is not possible Sep 14 20:58:40 Only User Action where the User needs to intervene can happen Sep 14 20:59:00 now I'm confused Sep 14 20:59:23 DATA download via USSD is enabled in the USIM service table Sep 14 20:59:56 If the service is enabled, then the Send USSD can be used for the transport of data to the network Sep 14 21:00:09 Sure, but walk through it Sep 14 21:00:12 Send USSD -> OK Sep 14 21:00:24 Network Responds with User Action, DCS = Data Download Sep 14 21:00:32 We send an Envelope to the SIM with the USSD Sep 14 21:00:42 What can the SIM do? It is still in a session Sep 14 21:01:00 akiniemi, denkenz: Forget about the service activation stuff. We tried that with BlueZ and it was a big mistake. Don't even try to go there. It makes everything ten times more complicated. Looks nice on paper, but in reality it is not. Sep 14 21:03:12 Basically, Send USSD has 2 modes, one is MMI mode which is currently handled by the patches we have done now Sep 14 21:03:33 2nd Mode is Application mode Sep 14 21:04:36 USSD is considered as application mode when the service data download via USSD and USSD application mode is allocated and activated and DCS coding scheme is set to 8.bit data Sep 14 21:05:22 Yes, but what I'm saying is that if we receive a User Action, the SIM has to cancel the current session first Sep 14 21:05:33 So I don't see how this can work Sep 14 21:06:16 In MMI mode, when a user action is requested we dont send anything to the SIM Sep 14 21:06:25 SIM will still be in the USSD session Sep 14 21:06:36 Yep, that part makes sense to me Sep 14 21:07:20 Issue comes only when we the application mode is enabled and DCS is 8-bit data Sep 14 21:08:06 Sorry I'm still lost Sep 14 21:08:13 If we send a USSD in Application mode Sep 14 21:08:17 and the network responds Sep 14 21:08:31 Do we USSD Data Download and terminate then? Sep 14 21:08:51 31.111 is totally not clear here Sep 14 21:09:01 ys Sep 14 21:09:27 Or is it the case where USSD transaction to the network is different than USSD transaction from the network Sep 14 21:12:01 When more information is required by network, then it sends a network initiated USSD Sep 14 21:12:53 which is not the same USSD session which was started by ME Sep 14 21:13:00 See, here's my problem Sep 14 21:13:09 STK can have 1 proactive command active at a time Sep 14 21:13:17 yes Sep 14 21:13:32 So, if the SIM performs 'Send USSD' Sep 14 21:13:43 And the Network replies with USSD Data Download message Sep 14 21:13:56 The SIM cannot have a dialog with the network without canceling the previous command Sep 14 21:14:42 So my question is, if it is a USSD Data Download, then should we send back a Terminal Response with no 'Text' object in addition to the USSD Data Download envelope Sep 14 21:15:43 Yep Sep 14 21:15:59 Ok, that makes sense Sep 14 21:16:10 Do you know the order? E.g. Envelope first or Terminal Response first? Sep 14 21:16:30 Terminal response first Sep 14 21:16:48 May be i can reconfirm it Sep 14 21:16:56 Can you check? 31.111 does not say anything Sep 14 21:17:35 Note: for all this things, we need to have the information available in the SIM service table Sep 14 21:18:34 We already read the UST/EST & SST Sep 14 21:18:40 So that info is available Sep 14 21:22:04 do I need to handle that also in this patch? Sep 14 21:22:22 Don't worry about the Application mode for now Sep 14 21:22:27 Lets get the regular one in Sep 14 21:22:35 Add a task for USSD Data Download too Sep 14 21:22:40 ok Sep 14 21:22:52 There is one more thing Sep 14 21:23:19 we can also upate the picx set with USSD data download not supported Sep 14 21:23:54 picx set? Sep 14 21:26:26 basically information containing what the ME supports. That will be used as input to the conformance test setup. I might have mispelled it Sep 14 21:27:47 Ah, nod Sep 14 21:29:03 If we're ready for compliance testing this quickly then we're doing pretty good ;) Sep 14 21:30:50 I have one valid point for FDN phonebook Sep 14 21:32:14 what if the SIM which has FDN activated used with the Mobile phone which doesn't support FDN Sep 14 21:32:57 I mean FDN phonebook, user knows the fixed dialing is active but he doesn't know what are the numbers stored in the FDN phonebook Sep 14 21:34:04 This might be one valid point for adding SIM FDN phonebook support Sep 14 21:37:54 Jeevaka: Normally these are called PICS in most conformance test suites. Sep 14 21:37:55 Jeevaka: The current thought is that oFono will check whether FDN is active, and if so will go into emergency mode Sep 14 21:38:18 ok Sep 14 21:38:44 holtmann: got it, thats why said I might have mispelled it Sep 15 00:39:23 denkenz: any comments for dun patches? **** ENDING LOGGING AT Wed Sep 15 02:59:57 2010