**** BEGIN LOGGING AT Mon Jul 26 02:59:57 2010
**** BEGIN LOGGING AT Mon Jul 26 05:00:15 2010
Jul 26 10:17:03 <zhenhua> denkenz: bug #4001 looks really weird to me.
Jul 26 10:17:08 <zhenhua> denkenz: http://bugs.meego.com/show_bug.cgi?id=4001
Jul 26 14:01:23 <luke-jr> so is Finland vacationers back yet? :p
Jul 26 14:03:38 <kvalo> luke-jr: depends
Jul 26 14:03:53 <luke-jr> kvalo: oh hello, didn't know you used IRC :P
Jul 26 14:03:59 <kvalo> some minority of finns come back from vacation this week
Jul 26 14:04:06 <luke-jr> ah
Jul 26 14:04:11 <kvalo> luke-jr: I try to avoid using irc
Jul 26 14:04:28 <luke-jr> anyone who can help me get oFono working on N900? ;)
Jul 26 14:04:29 <kvalo> luke-jr: but I would say that it takes two weeks still before finland is back in action :)
Jul 26 14:07:19 <luke-jr> is that a "no"? :p
Jul 26 14:07:32 <kvalo> luke-jr: I have been using n900 through usb cable from my laptop. is that enough? :)
Jul 26 14:07:53 <luke-jr> not sure, does it interact the same way w/ phonet?
Jul 26 14:08:09 <kvalo> no idea
Jul 26 14:09:31 <luke-jr> hm
Jul 26 14:09:56 <luke-jr> kvalo: any idea how C-Bus mainlining is coming along btw? when people don't use IRC, it leaves others in the dark ☺
Jul 26 14:10:43 <kvalo> I haven't worked with n810 at all this year :(
Jul 26 14:11:03 <tmzt> what's c-bus?
Jul 26 14:11:48 <kvalo> nokia proprietary serial bus used in n800/n810
Jul 26 14:11:52 <luke-jr> tmzt: some SPI-like bus in Nokia tablets
Jul 26 14:12:04 <luke-jr> tmzt: basically the big blocker to getting real Linux support on them
Jul 26 14:12:26 <tmzt> related to power management?
Jul 26 14:12:33 <luke-jr> no
Jul 26 14:12:38 <luke-jr> well, that too maybe
Jul 26 14:12:43 <luke-jr> but it's just a bus
Jul 26 15:23:02 <denkenz> kvalo: Sounds like the kernel is reporting HUP in an infinite loop maybe?
Jul 26 15:24:16 <denkenz> e.g. it disconnects, huawei.c re-opens the device, it disconnects
Jul 26 15:24:18 <denkenz> etc
Jul 26 15:26:30 <kvalo> denkenz: I did a quick debug session and to me it looks like gprs_context_remove() goes to io_disconnect() and then to huawei_disconnect() again
Jul 26 15:28:22 <kvalo> denkenz: I can't debug it today, but can continue tomorrow
Jul 26 15:29:12 <denkenz> kvalo: Yeah, basically when GAtIO detects a disconnect it signals the disconnect function
Jul 26 15:29:34 <denkenz> kvalo: The GAtPPP disconnect function gets set, so ppp_disconnect gets called in drivers/atmodem/gprs-context.c
Jul 26 15:29:51 <denkenz> Then when g_at_chat_resume is called, the state of GAtIO is queried
Jul 26 15:30:01 <denkenz> If it is disconnected, then GAtChat disconnect function gets called
Jul 26 15:30:30 <denkenz> So if the modem asserts HUP for several seconds, you might see quite a bit of these
Jul 26 15:31:22 <denkenz> Someone with more serial programming experience might be helpful here, since I've no idea whether this HUP is somehow a serial fd specific thing
Jul 26 16:51:57 <padovan> denkenz: which action should trigger the start of a DUN connection? org.ofono.Modem.Connect()?
Jul 26 16:52:30 <denkenz> Nope, just uses the same API as doc/data-connection-manager.txt
Jul 26 16:58:19 <padovan> So I won't use org.ofono.Modem, right?
Jul 26 17:01:08 <denkenz> nope
Jul 26 17:01:20 <denkenz> The only thing from Modem you want is the powered stuff
Jul 26 17:01:28 <denkenz> Similar to hfp, e.g. for establishing the rfcomm link
Jul 26 17:03:23 <padovan> Right.
Jul 26 17:25:06 <holtmann> padovan: For DUN client you need a SIM atom driver, a netreg atom driver and GPRS atom drivers (if the generic ones can't be re-used).
Jul 26 17:25:26 <holtmann> That should be it. A DUN client device should not export anything else.
Jul 26 17:27:02 <padovan> Sure, I'll work on that drivers
Jul 26 17:33:38 <holtmann> And then just have plugins/dun.c for the DUN plugin itself. It just needs to register SIM, NETREG and GPRS atoms.
Jul 26 17:33:51 <holtmann> If you wanna be fancy then we could also have devinfo, but that is not really useful.
Jul 26 17:34:56 <padovan> Ok.
Jul 26 17:50:48 <denkenz> sim atom is actually not necessary
Jul 26 17:51:01 <denkenz> I already did that hack for hfp
Jul 26 17:59:57 <holtmann> Sweet.
Jul 26 18:00:00 <holtmann> So it should be pretty easy.
Jul 26 18:16:42 * balrog-k1n thinks 'SMSManager' and 'SIMManager' are both correct CamelCase ;)
Jul 26 18:17:31 <balrog-k1n> however SMS Message makes no sense, 'SMS' or 'ShortMessage' would make sense
Jul 26 18:18:16 <denkenz> Nope, we're pure CamelCase, abbreviations vs not don't matter
Jul 26 18:19:04 <denkenz> And fair enough on SMSMessage, feel free to point that out to Inaky
Jul 26 18:19:15 <denkenz> Personally I'd rather see 'Message'
Jul 26 18:19:45 <balrog-k1n> Message also looks good
Jul 26 18:20:51 <holtmann> I prefer TextMessaging instead of SmsManager btw.
Jul 26 18:20:53 <holtmann> Or just "Messaging".
Jul 26 18:21:03 <denkenz> Too generic
Jul 26 18:21:15 <balrog-k1n> SIMManager would be pure CamelCase to me, as SIM is not really a single word, it's three words so each should be capitalised the same
Jul 26 18:21:18 <holtmann> I already renamed CBS into CellBroadcast.
Jul 26 18:21:40 <holtmann> denkenz: That is the point. It should be so generic that we can even use it for CDMA.
Jul 26 18:21:45 <holtmann> Or anything else we ever wanna do.
Jul 26 18:21:54 <inakypg> hmm
Jul 26 18:22:11 <inakypg> so what's the veredict?
Jul 26 18:22:55 <denkenz> balrog-k1n: I've had this argument so many times before, in the end CamelCased abbreviations still look better
Jul 26 18:22:58 <denkenz> e.g. see Qt APIs
Jul 26 18:23:16 <denkenz> holtmann: CDMA also refers to it as SMS, so not helping
Jul 26 18:27:13 <denkenz> inakypg: My preference is to just name that interface 'Message' and be done with it
Jul 26 18:28:06 <inakypg> denkenz: disagree, there are too many unqualified messages and it gets confusing, specially when mms is added
Jul 26 18:28:20 <inakypg> so let's do SMSMessage or SmsMessage. Pick one, after all you are the maint.
Jul 26 18:28:24 <denkenz> mms is not being added to oFono
Jul 26 18:28:43 <inakypg> mms: meaning whichever side scratch it does on ofono
Jul 26 18:30:01 <denkenz> 'SMS Message -> Short Message Service Message' as balrog-k1n pointed out
Jul 26 18:30:09 <denkenz> That seems a bit silly
Jul 26 18:31:11 <balrog-k1n> TextMessage also sounds good, using holtmann's idea
Jul 26 18:31:29 <balrog-k1n> both sms and ems are text but not mms
Jul 26 18:31:51 <denkenz> EMS is closer to MMS than SMS
Jul 26 18:32:13 <balrog-k1n> but didn't we want to use the same API for EMS?
Jul 26 18:32:18 <denkenz> Nope
Jul 26 18:32:23 <denkenz> Lets put it this way:
Jul 26 18:32:37 <denkenz> MMS has no API in oFono and won't
Jul 26 18:32:53 <denkenz> You will get PUSH notifications, but that will end up being something like MmsPushNotification
Jul 26 18:33:14 <balrog-k1n> then EMS is not a text message, so TextMessage still sounds ok
Jul 26 18:34:11 <denkenz> Disagree, we have SmsManager -> array{object} Messages -> Message
Jul 26 18:34:19 <denkenz> That makes perfect sense to me
Jul 26 18:35:05 <balrog-k1n> this one makes sense
Jul 26 18:35:10 <balrog-k1n> yes, but then you have org.ofono.Message interface which doesn't mention test or sms
Jul 26 18:35:19 <balrog-k1n> text*
Jul 26 18:36:17 <denkenz> If our API becomes so bloated we need to qualify it, we failed
Jul 26 18:37:14 <balrog-k1n> well, if the same interface can be used for other type of messages then it's ok obviously
Jul 26 18:38:00 <denkenz> It might be that EMS reuses this
Jul 26 18:38:13 <denkenz> But most likely not
Jul 26 18:42:41 <denkenz> In the end I'm fine with either
Jul 26 18:53:39 <denkenz> inakypg: Go ahead and do SmsMessage for now
Jul 26 20:19:36 <denkenz> inakypg: So I don't like the implementation of the msg id hashing stuff
Jul 26 20:20:42 <denkenz> inakypg: Seems to me just a simple function that takes a GSList of sms pdus would be enough
Jul 26 20:29:01 <ljp> fyi: huawei E220 seems to work ok
Jul 26 20:29:32 <denkenz> git or a tagged release?
Jul 26 20:30:55 <ljp> whatever is for ubuntu :)
Jul 26 20:56:49 <jprvita> inakypg: you're the one working on SMS, right? do you have a public git tree somewhere?
Jul 26 21:08:08 <inakypg> jprvita: yep
Jul 26 21:09:17 <inakypg> jprvita: git://gitorious.org/~inakypg/ofono/ofono-inakypg.git
Jul 26 21:09:49 <jprvita> cool, I'm trying to understand better the SMS manager
Jul 26 21:10:25 <jprvita> actually, my first intention was to do exactly what you've already done :)
Jul 26 21:10:40 <jprvita> I'll do some tests them
Jul 26 21:10:50 <jprvita> inakypg: ^
Jul 26 21:11:05 <jprvita> but tomorrow, time to go home now :)
Jul 26 21:13:06 <inakypg> jprvita: just be careful because I am rebasing it a lot while we try to merge the changes
Jul 26 21:13:49 <jprvita> inakypg: I can imagine..  thanks for reminding me
Jul 26 21:14:17 <jprvita> so tks, see you around
Jul 26 21:46:41 <denkenz> inakypg: did you see my comment earlier?
Jul 26 21:47:45 <inakypg> denkenz: abvout SmsMessage?
Jul 26 21:47:56 <denkenz> No, about the Message ID api
Jul 26 21:49:29 <inakypg> denkenz: nope, sorry, I got disconnected
Jul 26 21:53:30 <denkenz> denkenz: inakypg: So I don't like the implementation of the msg id hashing stuff
Jul 26 21:53:31 <denkenz> [3:20pm] denkenz: inakypg: Seems to me just a simple function that takes a GSList of sms pdus would be enough
Jul 26 21:56:59 <inakypg> denkenz: the whole thing is designed in such a way that implementing a helper function that does that is relatively trivial -- I tend to dislike your preference of doing things over GSlists because you kill type checking that can catch silly issues, but it is still doable
Jul 26 21:57:49 <denkenz> So my thinking is as follows, both the SMS Assembly and the SMS TX Q work on GSLists of struct sms
Jul 26 21:58:30 <denkenz> Something that basically takes those as input to generate a message id is ideal
Jul 26 21:59:02 <denkenz> And I don't buy the GSList argument
Jul 26 22:00:14 <denkenz> So the question is, can you do it based on struct sms, or do it based on the 23.040 pdu format
Jul 26 22:00:28 <inakypg> not disagreeing, just saying that using  GSLists as parameters and assuming what's behind the nodes is always the same type is a risky business, specially in code that is evolving as fast as oFono is. You don't have to buy it, it is my opinion. You loose the compiler's ability to catch those silly errors.
Jul 26 22:00:46 <inakypg> denkenz: I'll add the helper
Jul 26 22:01:08 <inakypg> and please, *stop* changing the commit messages, just tell me what you want changed
Jul 26 22:01:22 <denkenz> Just doing a helper isn't enough
Jul 26 22:01:26 <inakypg> it's being a pain to get my git tree in shape and to figure out what you want so you don't have to change it again
Jul 26 22:01:57 <denkenz> Seriously, I will not stop amending simple git header commits
Jul 26 22:02:30 <denkenz> You can minimize it by doing it like I do them, but not end it completely
Jul 26 22:04:20 <inakypg> denkenz: sorry I am on the phone, brb
Jul 26 22:34:17 <inakypg> denkenz: I am trying to do headers like you like them, but if you change them without saying exactly (and documenting) your likes, you make it quite difficult for me (or anyone else for that matter) to learn your likes and from our mistakes--we'll  be honestly making them every now and then and the best way to not repeating is to be told: redo this this way
Jul 26 22:36:44 <inakypg> denkenz: on the sha stuff, please put it over email -- I want to have something to refer to when IRC dies -- what do you mean with helper isn't enough?
Jul 26 22:53:08 <denkenz> inakypg: You do know how I did it, git log ;)
Jul 26 22:53:52 <inakypg> denkenz: the only non-obvious one is s/SMS/sms/, the rest, I have no idea -- don't be lazy -- document them and say them
Jul 26 22:54:02 <inakypg> you will be glad on the long term :)
Jul 26 22:54:09 <denkenz> inakypg: That is seriously it actually ;)
Jul 26 22:54:40 <denkenz> inakypg: All you have to do is diff the git header
Jul 26 22:54:58 <denkenz> inakypg: I never git amend the patch contents
Jul 26 22:55:56 <inakypg> denkenz: I know it seems pretty simple, and I understand your motivation as a time saver for you to do it, but the fallback on the contributor is way higher to no gain on the long term. diffing the header is easy, yes, times X messages plus then fixing the trees to fix the conflicts it generates adds to a non-trivial amount of time
Jul 26 22:56:22 <inakypg> way more than it would have taken you to say what you didn't like, me to fix it and just rebase that commit for the next resubmit
Jul 26 22:56:52 <inakypg> I am not ocmplaining for the sake of it, I've been guilty of doing the same in the past and rightfully beaten to it by contributors.
Jul 26 23:01:33 <denkenz> inakypg: Seriously, I told you exactly what I changed, you figure out what changed, if there's a question _why_ it was changed, talk to me
Jul 26 23:02:00 <denkenz> Rejecting a patch, having you come back a week later and me trying to figure out whether I'm OK with it takes too long
Jul 27 00:01:15 <lpotter> I am curious why NetworkRegistration 'Technology' property is optional
Jul 27 00:11:02 <denkenz> because some modems don't report it
Jul 27 00:11:22 <denkenz> Not to mention pseudo-modems like HFP
Jul 27 00:11:30 <denkenz> Hence you can't rely on it being there
Jul 27 00:28:45 <lpotter> I figured it was something like that.
Jul 27 00:55:32 <lpotter> hmppft
**** ENDING LOGGING AT Tue Jul 27 02:59:56 2010