**** BEGIN LOGGING AT Thu Sep 02 02:59:58 2010
Sep 02 09:38:58 <zapp42> kvalo: Hi, may I bug you again (regarding ofonos huawei plugin)?
Sep 02 09:40:19 <kvalo> zapp42: sure. I have to leave soonish, but I can check your messages from awaylog after I come back
Sep 02 09:41:06 <zapp42> kvalo: I see a 255 for sim state in the sysinfo result when I plug in my device while ofono is already running...
Sep 02 09:41:38 <zapp42> How is a change in state (once the sim is initialized) supposed to be detected?
Sep 02 09:42:00 <kvalo> I see the same with my huawei e1552. I sent some patches few weeks ago, did you see them?
Sep 02 09:43:21 <zapp42> hmm. I saw some "fix sim state" stuff, but none from you. Will check again... ofono or connman list?
Sep 02 09:43:36 <kvalo> ofono
Sep 02 09:43:42 <kvalo> I can find them for you
Sep 02 09:44:07 <zapp42> don't worry, I will find them. Thank you.
Sep 02 09:44:40 <kvalo> they need more work, but I was able to get my huawei working reliable after those two patches
Sep 02 09:44:53 <kvalo> I don't know if it helps you, though.
Sep 02 09:45:56 <zapp42> "huawei: properly notify sim state to ofono"
Sep 02 09:46:02 <zapp42> This one?
Sep 02 09:46:51 <kvalo> these two:
Sep 02 09:46:56 <kvalo>     huawei: poll sim state
Sep 02 09:47:00 <kvalo>     huawei: postpone post_sim until SIM is ready
Sep 02 09:47:19 <kvalo> zapp42: what's your email address? I can send them via email
Sep 02 09:48:41 <zapp42> kvalo: Thanks. Did you get my address? I am not too familiar with irc..
Sep 02 09:49:25 <kvalo> zapp42: got it. sent the two patches now
Sep 02 09:49:52 <zapp42> Already there. Thanks a lot.
Sep 02 09:50:20 <kvalo> I need to work on the patches more, denis found problems with them.
Sep 02 09:50:59 <kvalo> I will leave soon, but I should back in an hour
Sep 02 11:48:39 <pessi> denkenz: I have no idea how to do it with an AT modem. On isimodem, we get an SS indication. As it is a US-specific addition to the requirements. I'll have to find out if we can even do testing here
Sep 02 13:29:39 <denkenz> pessi: These are still independent
Sep 02 13:30:17 <denkenz> pessi: We also have the problem of when to trigger Offline state in emergency-only mode after the emergency call is over
Sep 02 14:23:13 <pessi> denkenz: I'm trying to solve that with the EmergencyCallOnGoing property and perhaps with a corresponding wait?
Sep 02 14:23:48 <pessi> but we now quite a lot of moving parts
Sep 02 14:24:29 <denkenz> Yes, but EmergencyCallOnGoing when you have no calls makes no sense
Sep 02 14:24:53 <pessi> modem controls online/offline, voicecallmanager makes the call, and then some supplementary service blob talks to GPS
Sep 02 14:25:26 <denkenz> Yes, so perhaps the Modem object should have an EmergencyMode and set_emergency_mode
Sep 02 14:25:35 <denkenz> and several atoms can influence that
Sep 02 14:25:38 <pessi> "EmergencyMode"
Sep 02 14:25:41 <denkenz> Just throwing an idea around
Sep 02 14:25:52 <pessi> thanks ;)
Sep 02 14:26:49 <pessi> something like emergency_mode_ref() and _unref() (or _inc()/_dec())
Sep 02 14:27:25 <denkenz> yeah
Sep 02 15:18:32 <pessi> denkenz: I sent todo mods, please have a look on them
Sep 02 15:27:23 <denkenz> pessi: In general I'd like to keep words like 'figure out' from the TODO items
Sep 02 15:27:40 <denkenz> pessi: Especially in the first sentence ;)
Sep 02 15:29:01 <denkenz> It is fine to be wrong, but the task should contain enough hints and direction for someone else to read the description and have a direction to go in
Sep 02 15:30:10 <denkenz> for the emergency property, label it experimental
Sep 02 15:30:15 <pessi> denkenz: it is genuince marcel, I copied it ;)
Sep 02 15:30:18 <denkenz> But otherwise I'm fine with path 2
Sep 02 15:30:28 <denkenz> s/path/patch
Sep 02 15:31:05 <pessi> denkenz: I'm trying to recruit our emergency call guru to do this ;)
Sep 02 15:31:43 <denkenz> pessi: Just reword it to say 'Proposed solution is to...'
Sep 02 15:31:50 <denkenz> We can always modify it if needed
Sep 02 15:33:23 <denkenz> pessi: Good idea, we have no emergency call Gurus or a network we can initiate them on
Sep 02 15:33:37 <denkenz> pessi: Doubt my local fire department would appreciate me calling around for testing ;)
Sep 02 15:35:51 <pessi> naah. nothing spices the day more than a tired lady answering your call with "Hätäkeskus - nödcentralen. Kuinka voin auttaa? Hur kan jag hjälp?"
Sep 02 15:38:05 <denkenz> I'll take your word for it ;)
Sep 02 15:41:12 <holtmann> pessi: What did I do now?
Sep 02 15:42:12 <pessi> holtmann: probably nothing, but it always convenient to blame you
Sep 02 15:44:21 <pessi> it was denis' text I copied. no wonder he was not happy with it ;)
Sep 02 15:48:26 <denkenz> I don't see any words like 'Figured out' in the TODO
Sep 02 15:48:38 <denkenz> If there are, then its my bad and it needs to be fixed
Sep 02 15:49:44 <denkenz> Some of the TODO items were done rather quickly and need to be fixed up
Sep 02 15:58:47 <pessi> you have to clean emergency number list, i believe
Sep 02 16:00:53 <pessi> the Dial method, should it return both path and property dict, or should we ensure that CallAdded is always emitted before Dial returns?
Sep 02 16:14:59 <denkenz> pessi: voicecall atom always emits signals after returning from the method call
Sep 02 16:15:29 <denkenz> pessi: What will you get from the CallAdded signal that you don't already know from invoking Dial?
Sep 02 16:15:39 <pessi> why all the jazz with need_to_emit, then?
Sep 02 16:17:00 <denkenz> pessi: Some phones are actually weird, they signal unsolicited that call is dialing / alerting
Sep 02 16:17:06 <denkenz> But ATD returns only after
Sep 02 16:17:28 <denkenz> +call is connected
Sep 02 16:18:18 <pessi> uh
Sep 02 16:18:41 <denkenz> Sane firmware, ATD returns immediately and you get call progress indications after
Sep 02 16:19:48 <denkenz> So we try to be as nice as possible in guaranteeing the signal order
Sep 02 16:19:54 <denkenz> But sometimes we simply can't
Sep 02 16:21:08 <pessi> if dialer has to deal with CallAdded before Dial returns, I'd vote for emitting it always before Dial returning 
Sep 02 16:24:02 <denkenz> perhaps, we actually need to hear some feedback from UI guys here
Sep 02 16:24:17 <denkenz> There are other areas where this might need to be tweaked
Sep 02 19:17:15 <akiniemi> denkenz: so what's the use case justifying SMS bearer API?
Sep 02 19:18:09 <denkenz> akiniemi: Dunno, some big customer or other asked for it ;)
Sep 02 19:18:18 <denkenz> akiniemi: I'd personally want that one in main.conf
Sep 02 19:22:39 <denkenz> I'm just raising a question here, it might very well be useful to have Alphabet as something the user sees
Sep 02 19:22:47 <akiniemi> denkenz: wow, that's exactly the same use case we have for Alphabet ;)
Sep 02 19:23:47 <akiniemi> denkenz: S60 phones have both in the UI. Android seems to only have delivery reports and SMSC.
Sep 02 19:24:13 <akiniemi> And iPhone, I think, only has SMSC.
Sep 02 19:24:20 <denkenz> Certainly the 16 bit vs 8 bit stuff belongs in main.conf
Sep 02 19:24:49 <akiniemi> denkenz: no, that should just be 8bit when sending, recv naturally should support both.
Sep 02 19:24:51 <denkenz> Alphabet I can see, Bearer ... I'd really want to see in main.conf
Sep 02 19:25:25 <denkenz> Not sure, considering 23.040 explicitly recommends 16 bit headers
Sep 02 19:26:07 <akiniemi> But why?
Sep 02 19:26:16 <denkenz> collisions?
Sep 02 19:28:47 <akiniemi> You only get collisions if you wrap the ref while a multipart is in flight. Not likely.
Sep 02 19:29:20 <akiniemi> Anyway, all phones out there seem to use 8bit.
Sep 02 19:29:41 <akiniemi> And not to menton 16bit wastes a byte. ;)
Sep 02 19:30:27 <denkenz> Sure, but oFono can be used for M2M usecases
Sep 02 19:30:38 <denkenz> So dismissing something just because it doesn't fit a phone is also not a good idea
Sep 02 19:31:54 <akiniemi> denkenz: surely M2M needs the ability to send binary SMSs, no?
Sep 02 19:32:42 <denkenz> possibly, and I never argued against ability to send binary SMS messages
Sep 02 19:32:52 <denkenz> Just the ability to send them raw over D-Bus
Sep 02 19:33:12 <akiniemi> You mean a raw TPDU or just ay?
Sep 02 19:34:35 <akiniemi> Because I was thinking of adding SendBinary(string to, array{byte}, uint dest, uint src)
Sep 02 19:34:59 <akiniemi> where src == 0 means ephemeral
Sep 02 19:35:12 <denkenz> I'm really against this at this point
Sep 02 19:35:19 <denkenz> I only see the need to send VCards and VCals
Sep 02 19:35:24 <denkenz> This can have dedicated API
Sep 02 19:36:14 <akiniemi> That's then going to be a patch we need to carry in packaging...
Sep 02 19:36:45 <denkenz> Shrug, feel free to convince me
Sep 02 19:36:55 <denkenz> So far I'm seeing talk but no use cases
Sep 02 19:38:03 <holtmann> I think the bearer should be main.conf as well.
Sep 02 19:38:03 <akiniemi> http://developer.android.com/reference/android/telephony/SmsManager.html
Sep 02 19:38:06 <holtmann> But then we have to finally start creating support for main.conf in the first place ;)
Sep 02 19:38:40 <akiniemi> You'll find similar APIs in Symbian, Java MIDP, etc.
Sep 02 19:39:16 <akiniemi> And guys, minimal only works if you combine it with *complete* ;)
Sep 02 19:39:44 <denkenz> Showing crappy Java APIs is not helping your case here
Sep 02 19:39:56 <denkenz> We have never set out to build an Android replacement
Sep 02 19:40:18 <akiniemi> Who's "we"?
Sep 02 19:40:52 <denkenz> Tempting, but nah
Sep 02 19:42:52 <denkenz> Let me put it this way, oFono has never been intended as a general purpose - you can do anything telephony stack
Sep 02 19:43:03 <denkenz> We focus on the use cases that make sense, and we make those easy
Sep 02 19:43:52 <denkenz> This allows us to keep complexity down and reliability of our code up
Sep 02 19:46:14 <denkenz> The rest will take care of itself over time, even the 'completeness' part
Sep 02 19:46:30 <akiniemi> How is SendVCard(string to, ay) less complex?
Sep 02 19:47:14 <akiniemi> Or are you suggesting SendVCard(string to, string card), cause that's not going to work.
Sep 02 19:48:37 <akiniemi> oFono needs to stay out of the vCard charset business, because it ain't pretty and UTF-8. :)
Sep 02 19:49:06 <denkenz> shrug, you again have blinders on and only thinking about your Smart Messaging stuff
Sep 02 19:49:11 <denkenz> you can send VCards over EMS
Sep 02 19:49:24 <denkenz> And trust me, that isn't simple as SendBinary(data, port, src)
Sep 02 19:50:02 <akiniemi> denkenz: huh? What smart messaging stuff? Please explain.
Sep 02 19:50:25 <denkenz> Smart Messaging is the Nokia spec that uses the dest / src port addressing
Sep 02 19:50:33 <denkenz> There other ways to skin a cat
Sep 02 19:50:50 <denkenz> Besides, why should our UI writers have to go read some spec and figure out what source / port to use?
Sep 02 19:51:04 <denkenz> That is utterly stupid and one of the things we're explicitly trying to avoid
Sep 02 19:54:08 <akiniemi> denkenz: I'm not following you. I know of two ways: ports in IEs, plus 8bit UD
Sep 02 19:54:23 <akiniemi> and GSM 7bit and //SCKL23F4 crap at the beginning.
Sep 02 19:54:34 <akiniemi> What are you talking about?
Sep 02 19:55:53 <denkenz> There's also a way as an extended EMS object
Sep 02 19:57:06 <denkenz> Same goes for Images
Sep 02 19:57:15 <denkenz> And the formats are wildly different
Sep 02 19:58:44 <akiniemi> Ok, I'm not talking about sending images in SMS. That is utterly stupid and not something we support.
Sep 02 19:59:40 <denkenz> So back to my original question, what _do_ you want to support?
Sep 02 19:59:45 <denkenz> So far I'm only hearing vCard
Sep 02 20:04:39 <akiniemi> Sending binary data to an application port
Sep 02 20:07:06 <denkenz> and I want a Pony
Sep 02 20:08:48 <akiniemi> So this EMS crap, do you actually know of phones that use it to send vCards?
Sep 02 20:09:50 <denkenz> vCards? no, Images? definitely
Sep 02 20:10:47 <akiniemi> Because all of the phones I know use port addressing to send vCards and MMS to send images
Sep 02 20:11:05 <akiniemi> And use 8bit ref numbers
Sep 02 20:12:02 <denkenz> Shrug, and I had plenty of Ericsson phones that used EMS to send images
Sep 02 20:12:38 <akiniemi> yeah, back in the early nineties ;)
Sep 02 20:13:22 <denkenz> So? Who'd use SMS to send a vCard? That's also utterly stupid
Sep 02 20:13:55 <denkenz> Lets be realistic, sending binary SMSes is not really a use case these days anyway
Sep 02 20:14:11 <denkenz> Unless you wanna do WAP mass marketing or something
Sep 02 20:17:01 <denkenz> Same goes for about a bazillion other features in GSM, like advice of charge, bdn, fdn, all the stupid operator naming crap, and let us not mention sim toolkit
Sep 02 20:20:17 <akiniemi> Sure, but if having to support all that nonsense bothers you, then you're in the wrong business my friend ;)
Sep 02 20:20:50 <denkenz> That doesn't really bother me
Sep 02 20:21:43 <denkenz> what bothers me is kicking the can down the road and expecting some poor UI guy who has no freaking idea to clean up after me
Sep 02 20:22:02 <denkenz> Lets face it, every other telephony stack out there is described by this statement
Sep 02 20:25:43 <akiniemi> So? There is an equal number of developers having to send AT commands to a TTY because there isn't an API available to send SMS.
Sep 02 20:27:42 <denkenz> So make something better
Sep 02 20:27:57 <denkenz> Not take the easy road of at least its not the shittiest thing out there
Sep 02 20:29:13 <akiniemi> I'm trying.
Sep 02 20:31:12 <denkenz> I know, so help me understand why you think SendBinary is needed.  So far I'm only seeing a need for SendBusinessCard and SendAppointment
Sep 02 20:31:26 <akiniemi> Google for developers looking to send binary SMSs
Sep 02 20:32:22 <denkenz> I have before plenty of times, but these guys are building back-office type apps
Sep 02 20:33:02 <denkenz> Something likely done with Kannel or other software that talks directly to the SMSC
Sep 02 20:33:31 <akiniemi> 22:27 < denkenz> Sure, but oFono can be used for M2M usecases
Sep 02 20:33:43 <denkenz> M2M is different though
Sep 02 20:34:02 <denkenz> You're sending sensor info maybe once an hour point to point
Sep 02 20:34:08 <denkenz> Not 20000 marketing messages an hour
Sep 02 20:35:28 <denkenz> And these days M2M is migrating away from SMS to GPRS
Sep 02 20:35:57 <akiniemi> Forget it, GPRS has NATs
Sep 02 20:36:20 <denkenz> Not if you cut a deal with the provider
Sep 02 20:36:31 <denkenz> And still largely cheaper than SMS
Sep 02 20:38:02 <denkenz> And I'm actually totally fine if someone comes in and proposes an extension API to oFono for doing Mass marketing WAP emails
Sep 02 20:39:15 <denkenz> But if that day never comes and we maintained SendBinary for only that reason, then we were being silly ;)