**** BEGIN LOGGING AT Wed Jul 21 02:59:58 2010 Jul 21 11:03:27 denkenz, yang_office: do you think we should implement the Set up call command? it seems to be one of the ones that have to be implemented by firmware Jul 21 11:05:07 yang_office: have you started working on Set up call by any chance? Jul 21 11:05:27 balrog-k1n: not yet. Jul 21 11:05:38 ok Jul 21 11:06:07 I just finished reading EFust and EFest, which would be used by send ussd. Jul 21 11:11:37 the mbmmodem does not implement Set up call in firmware, so we have to implement it Jul 21 11:12:10 but the dbus api will be tricky Jul 21 12:02:48 I have the N900 which uses the isimodem driver, is there anyway to make ofono create a dev node to pass raw AT commands to oFono/isimodem rather than using dbus? Jul 21 12:03:13 any way* Jul 21 12:04:13 Termana: not at the moment, but AT emulation is being added Jul 21 12:09:02 Termana: I'm curious, what do you want exactly to do? Jul 21 12:20:00 kvalo, NITdroid project wants to use ofono to communicate with the n900's phonet modem and Android's RILD communicates over a dev node with AT commands (to my knowledge) Jul 21 12:20:13 pnatd is no good Jul 21 12:20:18 and closed source Jul 21 12:22:41 that sounds tricky Jul 21 12:26:18 kvalo, not if AT emulation is provided. Jul 21 12:27:12 We had it partially working with pnatd, it would see signal, but pnatd doesn't implement all AT commands, and so it doesn't work Jul 21 12:40:59 i think you can make a rild plugin of some sort to talk D-bus instead Jul 21 13:12:54 Termana: Using oFono behind rild is never going to work Jul 21 13:13:06 Termana: You're better off writing a rild plugin that uses ISI Jul 21 13:54:35 denkenz, on what grounds are you saying it won't work? The reference implementation of RILD relies solely on AT commands to communicate. If I can get ofono to communicate with isimodem with AT commands, then there should be no reason for it not to work, provided all the AT commands are there (unlike pnatd) Jul 21 14:06:46 Termana: on the grounds that I wrote most of oFono and I'm telling you it won't work ;) Jul 21 14:07:08 oFono AT emulation will never be fully featured enough Jul 21 14:19:29 Termana: in case you missed denkenz comments: Jul 21 14:19:35 17:06 < denkenz> Termana: on the grounds that I wrote most of oFono and I'm telling you it won't work ;) Jul 21 14:19:39 17:07 < denkenz> oFono AT emulation will never be fully featured enough Jul 21 14:20:26 AT emulation is not meant to be good enough for a telephony stack to function over the emulator Jul 21 14:21:16 If you want that, bypass oFono and implement your own ISI driver Jul 21 14:21:23 but if it gets better than it was meant to be then all the better i guess :) Jul 21 14:21:51 Doubtful, 27.007 call control is fucked Jul 21 14:22:05 So unless we start inventing our own call control extensions it will never be good enough Jul 21 15:22:26 Hi, I am planning on implementing cell tower-based positioning. Jul 21 15:23:00 I am trying to find the status of the neighboring cell info api Jul 21 15:23:15 I see there was mail about it in Jan and Feb 2010. Jul 21 15:23:42 But I do not see OFONO_CELL_INFO_H Jul 21 15:23:50 in the current source Jul 21 15:36:01 This capability is not yet enabled Jul 21 15:36:24 See ofono/TODO, search for Neighbor Cell Info Jul 21 15:36:37 So far no one owns this task Jul 21 15:36:53 Yes, I saw it in there Jul 21 15:37:29 If you're interested the first thing is to take formal ownership of the task and start making proposals on the mailing list for the API Jul 21 15:37:53 This way we have some idea who's doing what and not to interfere Jul 21 15:41:03 My main interest is in the positioning itself and not really in the API Jul 21 15:42:32 e.g. as a consumer? Jul 21 15:42:37 Right Jul 21 15:42:54 Then you might have to wait until someone is interested in being the provider :) Jul 21 15:43:28 I'd like to make something like gsmloc, but that "crowdsources" the cell tower position estimates Jul 21 15:45:05 and then automatically updates people's database Jul 21 15:45:16 so they can do the positioning "offline" Jul 21 15:46:03 Each user would have a small cache of the db Jul 21 15:47:40 Is anything wrong with the API proposed in Feb, or is it just that it hasn't been implemented? Jul 21 15:48:14 Honestly the core team has little experience with location services Jul 21 15:48:24 And we're really busy with other tasks Jul 21 15:48:34 So until we learn we can't really give good feedback Jul 21 15:49:01 So either someone else has to step up, or it has to wait / be custom for the particular hw Jul 21 15:50:42 OK. I will try the API for some hw we have and see how it goes. Jul 21 15:50:44 If you feel the API is great, feel free to reply to the mailing list and say so Jul 21 15:50:54 Any data points are actually useful Jul 21 15:53:00 Sounds good. I will let you know how it goes. The points already raised about polling and saving power made sense. Jul 21 15:53:34 I'll take what was said in Feb as a starting point, since it hasn't changed since then. Jul 21 15:54:42 great, looking forward to your findings Jul 21 15:55:51 denkenz: so i like the idea of splitting GetKey and GetInput into methods Jul 21 15:56:42 there are a couple of other things i want to ask, i'll ask here Jul 21 15:56:47 sure Jul 21 15:57:13 you moved to main menu to properties, but there's no method like Select() to actually make a selection Jul 21 15:57:31 also the main menu can have a default item etc, all the things that a non-main menu can have Jul 21 15:57:50 Yeah, there's one method missing from my proposal Jul 21 15:57:57 Select(id, object agent) Jul 21 15:58:44 The agent passed to Select overrides the current default agent for the duration of the session Jul 21 15:58:54 or when the agent dies Jul 21 15:59:03 About the default item Jul 21 15:59:10 I don't see that in the spec, where is the default given? Jul 21 15:59:31 let me check.. Jul 21 16:00:24 e.g. SelectItem has an ItemIdentifier object, I assume that is the default Jul 21 16:00:38 SetupMenu has nothing like it Jul 21 16:00:41 denkenz: yeah, actually i'm wrong, there's no default for the main menu Jul 21 16:02:13 so we can have two agents, one used when the action was started using the main menu and a default one Jul 21 16:02:29 Correct Jul 21 16:02:33 is there some way to send a "End Session" and unregister then current agent? Jul 21 16:02:53 My thinking is that the agent can simply die Jul 21 16:03:10 However, this might not work out Jul 21 16:03:14 So I'm open to suggestions Jul 21 16:03:35 to die, the dbus client that registered the agent needs to disconnect from dbus, right? Jul 21 16:03:49 Yep Jul 21 16:04:03 However, that is the typical use case IMO Jul 21 16:04:15 user starts an app to interact with STK, when he is done, he exits it Jul 21 16:05:40 Also, doesn't mbm at least send end session notifications directly from the modem? Jul 21 16:06:02 yeah, very reliably Jul 21 16:06:31 So that's another thing we can utilize Jul 21 16:06:52 when you send a "Go Back" or "End Session" and are supposed to land in the main menu it always sends a *STKEND Jul 21 16:06:53 either start an idle timer and end the session (and the agent) or do it based on the modem Jul 21 16:07:32 Or if we're back at the main menu Jul 21 16:08:10 i think we're not supposed to track when we're back at the main menu, the card needs to know and send a notification Jul 21 16:08:57 fair enough, then we rely on the modem driver / sim card to tell us Jul 21 16:09:33 for example SelectItem is not only used for menus, the card i have also uses it e.g. to let you choose an email from which you want to send a message if you have more than one address Jul 21 16:10:06 No you're right Jul 21 16:10:53 So lets assume the modem tells us when the session is ended Jul 21 16:11:02 And we make up some heuristic for the ones that don't Jul 21 16:11:56 it may be a timer in the driver maybe, but i think such modems will send it as a terminal command possibly Jul 21 16:12:09 sorry, proactive command Jul 21 16:13:08 yeah, maybe if the SIM sends us a new Setup Menu, then we assume prior session terminated Jul 21 16:13:29 Just need to try it out and see how well this works Jul 21 16:14:17 so i'm not sure if it's worth the complication with two agents and the main menu handled differently than select item -- it makes sense if there are really going to be two agents, Jul 21 16:14:29 but they would have to implement mostly the same things Jul 21 16:14:43 so maybe the home screen app should handle sim apps and should be the only agent Jul 21 16:15:06 since it has to implement select item, display text, etc anyway Jul 21 16:15:09 what do you think? Jul 21 16:15:45 by having the same api for main menu and for select item, we save code in the UI and in ofono (basically main menu is for free) Jul 21 16:15:57 That is my original suggestion Jul 21 16:16:08 And one I still feel is the easiest Jul 21 16:16:22 However, you and holtmann had some problems with it Jul 21 16:16:51 oh, i'm just not sure which is better Jul 21 16:18:45 Me either ;) Jul 21 16:19:13 holtmann's argument was that it would mess up the UI or make it not look right Jul 21 16:19:18 another problem with two agents that i can see is that when, say, an SMS triggers a display text, and the menu app is running, it will be sent to that agent even though normally it would go to the default agent Jul 21 16:19:30 and may confuse the user Jul 21 16:19:42 balrog-k1n: Yep, I raised this as well Jul 21 16:20:00 balrog-k1n: My feeling is these things are rare enough that it won't matter Jul 21 16:20:22 denkenz: yes, probably (if they happen at all) Jul 21 16:20:30 However, certainly a concern, and nothing we can do about them :( Jul 21 16:20:58 They do happen, but probably only with certain SIM apps Jul 21 16:21:20 There's a thing called STK interpreter which can trigger STK events based on SMS-PP downloads Jul 21 16:21:46 Almost all SIMs support it, but probably only certain networks do Jul 21 16:22:16 is that a special SIM, or like an app that is in some SIMs? Jul 21 16:23:12 we could fake the SMS-PPs from network if we knew what they look like Jul 21 16:23:26 just send envelopes to the card Jul 21 16:23:30 All major SIM vendors have their own STK interpreter Jul 21 16:23:41 There's even a 3GPP standard now Jul 21 16:24:01 However, you need to know the encryption key before your SMS-PP will be accepted Jul 21 16:24:20 So it is feasible, however I wasn't brave enough to try it out Jul 21 16:24:48 ok, doesn't sound too easy Jul 21 16:25:27 The format itself is fairly straight forward, it was the encryption that might be tricky Jul 21 16:25:36 a SIM i have uses all the basic commands except GetKey Jul 21 16:25:48 See 31.114 Jul 21 16:26:25 thanks, will check Jul 21 16:27:08 balrog-k1n: And we also have phonesim, plus I have some german SIMs with STK Jul 21 16:27:14 Unfortunately they're in German :P Jul 21 16:32:04 denkenz, holtmann: so, from the code simplicity pov, it's definitely easier for us and for the UI author to have just one agent, and add a [service].Error.SimToolkit.EndSession response to the other commands Jul 21 16:32:37 Please respond to the mailing list, I agree btw Jul 21 16:32:54 But lets have a wider discussion, maybe even our UI folks are listening Jul 21 16:33:09 ok, will do Jul 21 16:34:39 denkenz: one more question is about the help system thing, do you not want it in the api at all or just skipped from the document to make it clearer? Jul 21 16:35:28 the nice thing about it is that a ofono client can ignore the parameters if they don't support it Jul 21 16:35:49 Honestly I think the help system aspect is pointless Jul 21 16:35:58 And no phone I've seen implements it Jul 21 16:36:09 If you need help with a 4 item menu, then you're screwed :) Jul 21 16:36:29 Put down the phone and use one from the 1970s Jul 21 16:36:43 yeah, probably Jul 21 16:37:05 Again, I could be wrong, but that's my current thinking Jul 21 16:37:07 the two sims i tested don't have help for any of the menus or other commands Jul 21 16:37:16 It is also _very_ painful to explain to the UI writer Jul 21 16:37:53 Yeah, so I say we ignore it for now Jul 21 16:37:59 If someone complains we can think about it Jul 21 16:38:21 ok Jul 21 16:41:13 It is highly unlikely the SIM would have enough storage to make the help system work Jul 21 16:41:39 All of them require translations, so unless its something _very_ basic it probably won't be able to fit it in Jul 21 16:42:09 But who knows what these guys think up Jul 21 16:42:27 heh Jul 21 17:04:42 sabotage: I'd really like to hear from you on the STK stuff btw. You're the biggest expert on our UI Jul 21 18:22:58 denkenz: I'm on but rarely following in real time... summary (and no, ATM I don't have time to review the backlog unless it's less than say 20 lines Jul 21 18:23:26 * sabotage knows not what STK expands to either Jul 21 18:26:38 or tell me the backlog timestamp to start from and I'll see how far I get Jul 21 18:28:17 just see today's discussion Jul 21 18:28:28 and the stk proposal email from yesterday from me Jul 21 18:28:47 sabotage: I'm assuming you'll be the poor sob who has to implement the UI for it :) Jul 21 18:29:10 * sabotage shrugs Jul 21 18:29:18 Start at about 9AM PST Jul 21 18:29:27 * sabotage is used to being the "poor slob" Jul 21 18:29:40 usually more poor than slob but meh... Jul 21 18:29:46 lol Jul 21 18:30:03 Personally I prefer the opposite Jul 21 18:30:10 Being more slob than poor ;) Jul 21 18:30:43 unfortunately, a tendancy towards one always leads to the other :( Jul 21 18:31:19 one of those "natural rules" or something Jul 21 18:31:31 * sabotage starts by reading email Jul 21 18:31:33 fair enough Jul 21 18:36:28 denkenz: BTW, I'm starting to collect "minions" as we like to affectionately call them ;) Jul 21 18:36:42 Good :) Jul 21 18:37:11 so I may be able to delegate (one of the "areas for improvement" in my last review, learning to delegate ;) Jul 21 18:37:33 to which I repond, "ok, provide skilled labor" Jul 21 18:37:53 lol, that actually worked? Jul 21 18:39:28 meh Jul 21 18:39:59 I have some of my other tasks just now starting to be offloaded, though it's not looking like it will be a rapid hand off Jul 21 18:40:20 and then I do have two others owning up to adding missing features in dialer Jul 21 18:40:46 and they are decent/skilled troublemaker^w developers Jul 21 18:41:56 Well you guys definitely need the manpower Jul 21 18:41:59 and to anyone else listening... meego-handset-dialer now has a TODO file (thanks to inspiration from ofono) so feel free to start sending patches ;) Jul 21 18:43:03 Hey folks. :) Do i understand it right that for N900 support you use gisi + drivers/isimodem, and that there's basically no documentation about using ISI whatsoever, the best one can get is ofono sources? And why doesn't gisi/ hold all the binary constants needed to communicate with the modem and instead some headers in drivers/isimodem do? Jul 21 18:43:52 Today Nokia does not provide docs, they just provide the implementation Jul 21 18:44:25 All other questions are better asked on the list, its vacation time in Finland Jul 21 18:44:54 denkenz: Oh, vacation time, sounds nice :) Thanks for the answer. Jul 21 18:45:17 you can also search for the Nokia modem API Jul 21 18:45:24 It is largely based on ISI Jul 21 18:46:04 However, various modems from Nokia might implement or not implement it Jul 21 18:46:05 http://www.wirelessmodemapi.com/ Jul 21 18:46:05 denkenz: it's just that i thought that there would be a separate library usable for other projects, but in reality it appears like it's all reimplemented inside ofono and it's not really abstracted or documented. Jul 21 18:46:35 Not really sure why you thought that would be the case ;) Jul 21 18:47:45 Nice link, requires registration though :-O Jul 21 18:48:00 denkenz: RE STK... which spec will the ofono implementation be targeting? Jul 21 18:48:11 sabotage: ETSI 102.223 Jul 21 18:48:22 thanks Jul 21 18:49:15 sabotage: With things taken from 3GPP 31.111, but they're for parts that are not covered by 102.223 Jul 21 18:49:18 any considerations for 3G (I can't even recall if ofono does 3G) or 3GPP 31.111 Jul 21 18:49:23 ah Jul 21 18:49:46 Basically 31.111 does: "This is covered by 102.223, see that spec for details" Jul 21 18:49:51 for about 90% of the features Jul 21 18:49:57 heh Jul 21 18:49:59 So 102.223 is the 'primary' spec Jul 21 18:50:08 31.111 is for things which are GSM specific Jul 21 18:50:08 ok, /me has some reading to do then :( Jul 21 18:50:23 Under discussion today are non-GSM specific parts Jul 21 18:51:55 Also kill then steal or simply steal someone's iPhone / Nokia phone / Android phone with a foreign SIM card Jul 21 18:52:07 And play with Sim Toolkit there Jul 21 18:53:14 denkenz: define "foreign" SIM? Jul 21 18:53:29 Australian / German / UK Jul 21 18:53:38 oh :/ Jul 21 18:53:53 I've not seen STK on US providers Jul 21 18:54:55 * sabotage looks around and sees one of the UX guys from UK... and begins plot to swap SIMs Jul 21 18:56:12 If you can't find one, let me know Jul 21 18:56:26 I collect pre-paid SIMs from every country I visit, so I should have a few to spare Jul 21 18:56:49 ETSI.org website seems to suggest they want money from me to actually get the spec... Jul 21 18:57:12 No its free Jul 21 18:57:36 ah Jul 21 18:57:41 denkenz: as a matter of fact, the ofono ISI code seems to be clean and clear, quite readable, so lack of documentation shouldn't be a big problem assuming one can ask questions about details from time to time :) Jul 21 18:57:45 just found the "free pdf" link Jul 21 18:58:25 PaulFerster: oFono tends to facilitate that, however only the Nokia guys can answer the more detailed questions Jul 21 18:59:55 denkenz: the problem for real life usage of oFono as i understand it now is that it's not a complete telephony solution and that it lacks UI. Is it still the case? I wonder why N900 users are not using alternative oFono-based UIs yet. Jul 21 19:00:53 There is a Meego UI, the maintainer is even on this channel ;) Jul 21 19:00:56 denkenz: specific version of 102 223 or is latest ok? Jul 21 19:01:08 I see V9.1.0 Jul 21 19:01:11 sabotage: Latest is fine Jul 21 19:01:15 nod Jul 21 19:01:37 PaulFerster: There's also one from NeoPhysis, etc Jul 21 19:01:47 We build it, they will come Jul 21 19:02:51 PaulFertser: I am the author/maintainer of the MeeGo dialer app... I can share many, um, thoughts... yeah, that's the PC word, on the API from a GUI developers POV :P Jul 21 19:03:13 denkenz: what are you using for PIM integration? How does e.g. SMS messages are handled? Is it ready for everyday usage? Jul 21 19:03:13 o_O GACK!!! Jul 21 19:03:17 lol, start sharing ;) Jul 21 19:03:22 denkenz: is there any one huwei dongle that works best? or, rather, what would you recommend Jul 21 19:03:24 ETSI TS 102.223 == 209 pages! Jul 21 19:03:47 ljp: myself & holtmann test with E160G Jul 21 19:03:57 ljp: kvalo tests with E1552 Jul 21 19:04:11 I don't know of any other success / failure stories Jul 21 19:04:30 PaulFerster: oFono is not a one-stop shop solution Jul 21 19:04:41 cool, thanks Jul 21 19:04:45 denkenz: i know, but i lack bigger picture. Jul 21 19:04:47 PaulFerster: It never tried to be, we provide integration hooks but leave that up to system integrators Jul 21 19:04:57 Yeah, yeah, that's exactly why i ask :) Jul 21 19:05:08 PaulFerster: So for instance, Meego provides its own history plugin with EDS/Tracker backend Jul 21 19:05:26 denkenz: not EDS anymore... remember Jul 21 19:05:31 PaulFertser: http://matgnt.wordpress.com/2010/07/19/qt-ofono-d-bus-and-qml-part-1/ Jul 21 19:05:41 PaulFerster: Meego then has Dialer / SMS App that integrates with that history db Jul 21 19:05:57 sabotage: Is it only Tracker now? Good Jul 21 19:05:58 speaking of... whats the status of Raji's patches to get the sms/call history plugins in tree? Jul 21 19:06:14 sabotage: I commented on them and never heard back Jul 21 19:06:17 denkenz: the plugin is backend agnostic Jul 21 19:06:36 ljp: hey :) long time no see. How's life? Jul 21 19:06:39 emits DBus signal and listener owns saving and acking the events Jul 21 19:06:50 ok, I'll kick raji again Jul 21 19:06:51 sabotage: Ah yeah, that's right Jul 21 19:06:56 PaulFertser: good. complicated with 3 kids Jul 21 19:07:14 Should be lots of fun though ;) Jul 21 19:07:22 always Jul 21 19:07:40 denkenz: I also have a newer Huawei one. Jul 21 19:07:57 * sabotage grumbles at having to register with ETSI to get "free" docs... Jul 21 19:08:10 registration != "free" Jul 21 19:08:15 I don't think you need to register Jul 21 19:08:24 I simply enter my intel address and it lets me through Jul 21 19:08:37 * sabotage tried that Jul 21 19:08:42 said I had to reg Jul 21 19:08:51 which doc? Jul 21 19:09:25 holtmann: Which one do you have? Jul 21 19:09:37 denkenz: "ETSI TS 102 223 V9.1.0 (2010-04)" Jul 21 19:09:51 forcing me to reg to get it. Jul 21 19:09:57 ljp: So Qt finally gets QML support, nice :) EFL had Edje for some years already ;) Jul 21 19:10:22 sabotage: So I just put in my email into Users without an ETSI account and hit submit Jul 21 19:10:36 I just send it to you, sec Jul 21 19:11:05 denkenz: that's exactly what I've tried too Jul 21 19:11:08 denkenz: i wonder if you folks has faced some dbus-related issues? I mean libdbus oddities or some nastiness in dbus itself. Jul 21 19:11:12 with several versions of the doc too Jul 21 19:11:13 denkenz: It says E1800. Jul 21 19:11:17 no love Jul 21 19:11:29 kk, thanks for the end-run Jul 21 19:12:02 sabotage: sent Jul 21 19:12:36 sabotage: I still think registration is Free Jul 21 19:12:43 * sabotage watches to see if mail host falls over again ;) Jul 21 19:12:49 sabotage: Intel is a super-premium sponsor or something Jul 21 19:13:04 denkenz: sure, but I rather prefer not to register... Jul 21 19:13:14 PaulFertser: qml isn't about theming. its about animations mostly Jul 21 19:13:17 unless I'm going to be pulling specs regularly Jul 21 19:13:17 Fair enough Jul 21 19:13:32 PaulFerster: Nothing really stands out regarding DBus Jul 21 19:13:36 PaulFerster: It just works Jul 21 19:13:44 sabotage: Nah Jul 21 19:14:50 denkenz: so I take it most huwei dongles would work? like the E220? Jul 21 19:14:51 PaulFertser: I did run into some QVariantMap issues with the commonly used a{sv} dbus sigs on various methods Jul 21 19:15:24 had to create an explicit mapping in those cases Jul 21 19:16:19 ljp: That is the presumption Jul 21 19:16:29 ljp: The udev rules seem to be comprehensive now Jul 21 19:16:48 ljp: There might be hiccups due to firmware differences, but no way to tell until someone tries it Jul 21 19:17:43 denkenz: we definitely had problems with async dbus calls, i'll try to find a link to bugzilla now. Jul 21 19:19:48 denkenz: hehe, blocker: https://bugs.freedesktop.org/show_bug.cgi?id=19796 Jul 21 19:21:41 ljp: what do you think about the idea of a really powerful themes (Edje now even has a lua interpreter built-in)? Jul 21 19:22:36 PaulFerster: Good thing that function is never used in the core ;) Jul 21 19:22:41 sabotage: i'm kind of an UI developer too: using my own Emacs UI as an everyday phone ;) Jul 21 19:22:53 PaulFerster: Only some bluetooth stuff would be affected Jul 21 19:24:56 denkenz: the FSO folks always wanted to use nice and cool solutions, so we (fso users) are doomed to hit plenty of bugs in all of the FSO surroundings :) BTW, i think you can't deny Vala code does look quite nice ;) Jul 21 19:25:56 denkenz: but as an UI "developer" i've to admit FSO's API for telephony sucks being too low-level. Jul 21 19:26:01 PaulFerster: In the end nobody cares what language your telephony stack is written in. They only care about the external API Jul 21 19:26:43 denkenz: that's in fact not really true. I personally have bigger problems compiling FSO from the sources because it uses Vala. But OTOH i have bigger pleasure reading the code. Jul 21 19:27:32 PaulFerster: And a vast army of kernel / protocol / telephony hackers think the same about C Jul 21 19:28:19 denkenz: well, i'm sorta kernel hacker and i've never learned Python/C#, and have read plenty of C code. Jul 21 19:29:55 I'm not arguing against Vala looking beautiful, but then again, I've been complimented at how easily understood oFono code is Jul 21 19:30:02 * ljp waits for telephony in lisp Jul 21 19:30:05 Its just personal preference Jul 21 19:30:24 For oFono, using C made more sense and we can reach a wider audience / pay attention to resources better Jul 21 19:30:32 Other projects can use whatever they want ;) Jul 21 19:30:32 denkenz: i told the same 15 min ago: oFono is easily readable and that's really cool :) Jul 21 19:30:48 ljp: my Emacs UI is in elisp of course ;) Jul 21 19:32:42 PaulFertser: as a side note, regarding the DBus api... since now several apps and services in MeeGo are using both Ofono and Qt (MTF specifically) and dialer current has the "canonical" set of classes being used to simplify interaction with Qt, we're starting to work on spliting out the Qt classes we use to interact with Ofono into it's own library Jul 21 19:34:41 it's not official, but as soon I we have a branch that we can get working with MeeGo dialer, sms and contextkit provider plugins working, I'll make it public Jul 21 19:34:56 sabotage: well... i do not intend to troll but i personally dislike the way Qt uses C++ so i do not care much ;) (and the reason is that i think not using all the latest and greatest TR1/Boost/C++0x is "uncool"/"inelegant") Jul 21 19:35:21 fair enough Jul 21 19:36:15 I personally could care less except we started having 3,4,5 ... projects each copying a point in time version of my API/Classes and all now needing to be maintained w/in their own projects and kept in sync with Ofono Jul 21 19:36:26 just not maintainable Jul 21 19:37:42 sabotage: i mean Qt is not really unleashing the force of the C++ (for many various technical (backwards-compatibility with the projects and old compilers) and social (Qt should be usable even by less-than-guru-level programmer) reasons, so i understand why). But using a language in such a constrained manner sounds somehow "unfair" to me. Jul 21 19:38:07 nod Jul 21 19:38:24 sabotage: but thanks for the info anyway, i'll keep in mind there's an Qt oFono abstraction. Jul 21 19:38:53 So as an ex-Qt dev, I can say that for real projects Qt is about the best compromise available today Jul 21 19:38:55 but it *is* what MeeGo is using for App toolkits on Handsets and Tablets, and moreover, it *is* what libmeegotouch (MTF) is built on Jul 21 19:39:14 You do _not_ want to use all features of C++, even guru level programmers get lost Jul 21 19:39:22 so we )MeeGo handset app devs) at least are stuck with it ;) Jul 21 19:39:40 denkenz: that's another question: practical considerations vs beauty ;) Jul 21 19:39:50 Besides, it'll be hard to ignore Qt in the short term Jul 21 19:39:58 Especially for Meego Jul 21 19:40:00 sabotage: if i'm getting an n900, i'm using Debian + Emacs on it :P Jul 21 19:40:11 * sabotage goes AFK to locate and consume sustinance Jul 21 19:40:23 meh Jul 21 19:40:47 * sabotage considers starting a editor flame, but hunger wins out Jul 21 19:40:58 Anyway, back on topic guys ;) Jul 21 19:42:16 denkenz: i was considering making an Emacs UI for oFono based systems to cover a larger user-base. But for now it seems like there's no opportunity for that, everything's in flux and too little real-life users. So i did read oFono API ;) Jul 21 19:42:42 Its not that much in flux actually Jul 21 19:42:59 If you notice, the Voice aspects have been frozen since nearly project announcement date Jul 21 19:43:03 The reason i did it in Emacs is that it's really a nice framework for some Text-mode applications. Proved to be easy to start, easy to develop for, easy to use. Jul 21 19:43:33 denkenz: sure thing, but oFono alone is not enough for telephony anyway. And i wanted my contacts and messages support. Jul 21 19:44:09 Well, even those parts are not really in 'flux' Jul 21 19:44:17 The history API has been stable for a long time Jul 21 19:44:40 That's not to say some things won't change, they will, but the changes won't be drastic Jul 21 19:44:41 API is. But storage depends on the integrator etc. I just have no idea what to target. Jul 21 19:44:51 So roll your own Jul 21 19:45:08 sqlite3 / eds / tracker Jul 21 19:45:10 All good choices Jul 21 19:45:15 If there was a considerable real-life user base, i would. Jul 21 19:45:42 I think you will find that won't be a problem in a year or two ;) Jul 21 19:46:29 But it seems like n900 and gta02 are the only supported headsets for now and i haven't heard much about people using oFono+all-others-needed-technologies as an everyday phone. Jul 21 19:47:33 Remember, oFono has a slightly different audience Jul 21 19:47:39 Not hobbyists, but actual products Jul 21 19:47:47 To get that far requires more features + more effort Jul 21 19:47:56 Again, check back in a year or two Jul 21 19:48:03 I'll certainly do. Jul 21 19:48:10 :) Jul 21 19:48:12 Until then you're sort of stuck with rolling your own solution :) Jul 21 19:48:20 Or using FSO :P Jul 21 19:48:36 certainly Jul 21 19:49:12 That's not to say we don't welcome hobbyists Jul 21 19:49:33 But they have to realize what they're getting into, e.g. not a one-stop solution for a smartphone Jul 21 19:50:57 denkenz: it would be nice if there was an example "bigger picture" present somewhere on the website. Jul 21 19:51:33 bigger picture: meego Jul 21 19:51:37 The bigger picture is whatever you want it to be, oFono is not particular to Meego or smartphones Jul 21 19:51:57 e.g. you can take oFono + ConnMan and do a NetworkManager / ModemManager replacement Jul 21 19:51:57 denkenz: i know, but you've got to have some intergration glue. Jul 21 19:52:18 Or you can take oFono and do M2M type applications Jul 21 19:52:24 or Smart phones Jul 21 19:52:40 Possibilities are endless, we don't mandate anything really Jul 21 19:52:49 Just provide integration hooks Jul 21 19:52:55 The best example will of course be Meego Jul 21 19:53:07 ljp: i would prefer something i can apt-get... Can't really get the idea behind rolling out a new "distro". Jul 21 19:53:43 Meego packages can be ported Jul 21 19:53:48 Like the SMS app, or the Dialer Jul 21 19:54:22 However, that is not the realm of oFono Jul 21 19:54:33 Complaining about that here is not quite on topic ;) Jul 21 19:55:36 denkenz: is complaining about the folks who thought it's ok to take a 40 years old AT command interface, mangle it considerable and then write out a cryptic 3gpp spec on topic? ;) Jul 21 19:56:01 Sure Jul 21 19:56:24 You get bonus points if you call them idiots ;) Jul 21 19:57:43 Oh wow, nice, i'll keep in mind :) OTOH it's probably better to have a weird interface you need to write a strange parser for than to have a non-documented ISI ;) Jul 21 19:58:46 Seriously, we care about making the UI writer's job easy and doing the telephony aspects as nicely as possible Jul 21 19:59:10 I think i should look through your code to see how you solved the problem with various expected and unexpected replies and about unsols etc. Jul 21 19:59:36 For UI and integration we can help you, answer questions, etc Jul 21 19:59:46 Because there's a considerable and elegant architecture in FSO2 for that and we still ocassionally find bugs in there :/ Jul 21 19:59:46 But we're not actually involved in the integration aspects Jul 21 20:00:06 Also, see http://meego.gitorious.org/meego-handset-ux Jul 21 20:00:49 Sure, have a look at gatchat/gatchat.c Jul 21 20:01:08 It turned out pretty well I think, handles all the AT crap nicely Jul 21 20:02:11 denkenz: (making UI easy to do) well, we'll see how it goes. Probably you've choosed exactly the right level of abstraction to not limit UI too much. Jul 21 20:03:59 Thanks for that, I certainly hope so Jul 21 20:04:34 I'm always afraid of simplicity, especially when one talks about the developers. Things should be simple and elegant, of course. But if one tries to make it too simple, one limits his user. Jul 21 20:04:45 At least in my experience the most powerful tools have a steep learning curve. Jul 21 20:06:14 Sure, however oFono tries to pick its battles and chooses usecases to expose very carefully Jul 21 20:06:30 Sincerely wish you good luck with that. Jul 21 20:06:34 Certainly you can't do some of the more bizarre things with the current D-Bus API Jul 21 20:06:44 However, nothing is stopping you from providing extensions / plugins Jul 21 20:09:48 denkenz: i still have that feeling that it would be nicer if you sent some letter to the FSO mailing list explaining in details why you wanted to not join FSO development back in the days before the official announcment of oFono. I still remember that uneasy feeling i (and i assume most of the FSO folks) had when they read the oFono announcement, it felt kinda unfriendly. Jul 21 20:10:21 I'd just get flamed ;) Jul 21 20:11:45 If you look at our presentations we explained our position pretty well Jul 21 20:11:49 denkenz: if you try to look at what happened from the other POV, you'll see what i'm talking about. I think you (and other oFono devs, hi, holtmann :) ) are nice folks, so the next time you'll try to take others feelings and emotianal response into account. Jul 21 20:12:18 I am missing the context here. What are you talking about? Jul 21 20:12:45 quote: PaulFertser: denkenz: i still have that feeling that it would be nicer if you sent some letter to the FSO mailing list explaining in details why you wanted to not join FSO development back in the days before the official announcment of oFono. I still remember that uneasy feeling i (and i assume most of the FSO folks) had when they read the oFono announcement, it felt kinda unfriendly. Jul 21 20:12:50 denkenz: to be honest, it totally felt like NIH and "desire to control" for the fso guys. Of course, they're prejudiced, but you knew about that in advance. Jul 21 20:13:25 PaulFerster: Again, we clearly laid out our reasons. Some might no longer be relevant or less relevant now Jul 21 20:13:36 holtmann: in fact we had a nice talk about ISI, oFono code readability (it's great), 3GPP designers etc. Jul 21 20:13:40