**** BEGIN LOGGING AT Thu May 27 02:59:57 2010 May 27 06:39:16 denkenz: I will send the patches to use sim_extract_bcd_number() May 27 13:14:46 pessi: Is this something I broke or this is a general condition? May 27 14:34:44 for modems that implement set_online, do clients need to set it or is it set by default? May 27 14:38:52 balrog-k1n: Unclear, we need holtmann's take on how to handle this in connman too May 27 14:40:32 I'm trying to keep things simple for now until we understand all the interactions May 27 14:48:31 balrog-k1n: Tell me what you think of [PATCH 1/8] stk: Make parse_dataobj not consume extra data May 27 14:54:01 * balrog-k1n tries to wrap his head around it May 27 14:54:27 looking at the structure of launch browser helps May 27 14:59:48 denkenz: couldn't the file references list in launch browser be handled same way as the item list? or is the problem somewhere else? May 27 15:01:43 that's what I'm thinking, however, this only works when the last entry parsed is mandatory May 27 15:02:09 true, May 27 15:02:22 so the way around it is to parse the Bearer on its own May 27 15:02:36 and that's the solution I'm thinking of right now... May 27 15:04:01 denkenz: the patch makes sense to me, if parse_dataobj calls _next at the start it shouldn't do at the end May 27 15:04:24 denkenz: but it should be possible to avoid calling parse_dataobj multiple times May 27 15:05:57 it could take a flag for list of objects, the flag would be passed to handler_for_type which would return a different handler May 27 15:06:45 we tried it, becomes nasty May 27 15:07:10 you have to know the sizeof the struct you're parsing May 27 15:11:00 denkenz: how about not calling comprehension_tlv_iter_next at the beginning of parse_dataobj? May 27 15:11:37 it would have to be called once in stk_command_new_from_pdu May 27 15:11:52 yeah I thought of that as well May 27 15:13:18 that one could actually work May 27 15:14:03 yeah, seems better than not consuming data at the end and having to do the iter_copies May 27 15:17:38 balrog-k1n: Only one problem May 27 15:17:55 balrog-k1n: Some commands are actually empty, like polling off May 27 15:18:21 so doing iter_next in stk_command_new_from_pdu is tricky May 27 15:19:51 i think there's another problem too, sometimes you may call parse_dataobj with the last dataobj optional May 27 15:20:08 parse_dataobj will iterate till the end of the list if i'm reading it right May 27 15:20:46 it shouldn't May 27 15:20:48 or rather the end of the pdu May 27 15:20:53 and can't be called another time May 27 15:21:53 it only calls iter_next if the parsing succeeded May 27 15:22:03 oh yes, you're right May 27 15:22:05 or rather if the tags matched May 27 15:23:58 so now I'm questioning the need for this patch :P May 27 15:25:25 if the command is empty, it should also work if the return value from iter_next is ignored May 27 15:26:04 'work' sure, but we'd be missing some invalid cases May 27 15:27:05 in all cases i can think of (incorrect and correct structures) it would behave the same way May 27 15:33:57 except where all CTLVs are optional, which i think would not work right now if they were all missing May 27 15:34:27 a PDU with no CTLVs but all of them are optional, currently could not be parsed i believe May 27 15:35:04 yeah, but we don't have such a case May 27 15:37:21 actually, we do May 27 15:37:22 crap :) May 27 15:38:54 denkenz: What is the deal with online mode? May 27 15:39:25 holtmann: This is the rx/tx off but sim on mode May 27 15:40:15 And it is expected that ConnMan uses that when going into OfflineMode. May 27 15:40:25 potentially May 27 15:44:32 the language_notification_121 test is such a case, but it parses ok May 27 15:44:40 parse_dataobj handles this correctly, i was wrong May 27 15:45:18 yeah, because it gotos to out May 27 15:47:53 i still think we can ignore the result of the additional iter_next in the stk_command_new_from_pdu, the only case where it would matter is the the next mandatory CTLV was a "Result" ctlv May 27 15:48:30 alternatively we can replace the pdu with an empty pdu with a known invalid tag at the beginning when iter_next fails May 27 15:48:55 yeah, nasty :) May 27 15:49:16 we can certainly set the tag to an invalid one when iter_next fails May 27 15:49:30 however, I think we're going too far off here May 27 15:49:38 This is one specific case that breaks May 27 15:57:36 i think ts102223 6.10.4 and 6.10.5 say parse_dataobj needs to skip unknown CTLVs if the cr bit is zero May 27 15:58:40 yeah, but do we have unknown ctlvs? May 27 15:59:05 i mean unknown or unexpected May 27 15:59:52 and we do have some unknown tags ( > 0x7b) May 27 16:00:09 Well not really considering we implement the entire spec ;) May 27 16:00:16 At least for data objects May 27 16:00:47 what if the PDU has a 0x7c tag? May 27 16:01:30 i think that's what 6.10.4 is talking about May 27 16:01:47 and 6.10.5 is about the case where a random CTLV is inserted in the sequence May 27 16:02:09 yeah, we don't take care of that May 27 16:02:45 if we wanted to handle that, and be able to call parse_dataobj multiple times then we need to copy and restore the iterator anyway May 27 16:04:04 Yeah, except we'd need to provide the set of all expected tags May 27 16:04:44 We can certainly do it as a pre-parse step May 27 16:04:45 we already do that except in launch browser and setup menu May 27 16:07:22 gah I hate all of this :) May 27 16:07:27 * balrog-k1n starts thinking that all the TLVs would be easier to parse using a generic lex / flex grammar, and parsing would be extra fast May 27 16:13:01 doubtful it'll be faster than what we have now May 27 16:14:05 Please stay away from Flex or Bison. We just have found an issue that Bison now generates GPLv3 code. May 27 16:17:08 denkenz: certainly couldn't be slower, and i think it would be faster where we have huge switch ()es, and the iter copy and restore, etc May 27 16:18:04 denkenz: sent the bool patches to the list May 27 16:18:07 balrog-k1n: Seriously, stay away from Flex or Bison until I cleared the legal implications of their GPLv3 code generation. We have now GPLv3 code in BlueZ :( May 27 16:18:28 holtmann: just theoretising :) May 27 16:18:56 though i thought there was a clause somewhere in bison that the generated files could have changed the license to whatever license your program uses May 27 16:19:27 holtmann: do they stil include the "special exception" in the generated code? May 27 16:19:32 or something about an exception about linking with other licenses May 27 16:19:33 balrog-k1n: We are checking this. However problem is that autoconf/automake keeps a copy of the generated files. May 27 16:19:51 balrog-k1n: doubtful, bison is a fairly big hammer ;) May 27 16:20:34 pessi: is there still a concern from your side btw? May 27 16:20:41 pessi: Since I'm not getting it yet :) May 27 16:20:44 yeah, but what it generates in the end has just table lookups and almost no code May 27 16:21:24 you can't really beat it May 27 16:21:28 denkenz: simultaneous online->offline and sim removal will get core hosed ; May 27 16:21:46 the online->pre_sim can be handled in drvr May 27 16:22:18 balrog-k1n: Its still a giant switch statement, no way around it May 27 16:22:35 pessi: hmm, where does the crash happen? May 27 16:23:58 denkenz: well i'm too lazy to check in practice, but i'm convinced any hand written parser like ours, can only be slower because it just has more switches and ifs May 27 16:24:10 core still thinks its offline but it should be pre_sim May 27 16:25:14 pessi: Ah, so you're saying if I set_online and I get a sim removed event, then set_online callback fires May 27 16:25:36 balrog-k1n: Not really always true, been there done that May 27 16:25:46 balrog-k1n: But its a great experiment to try ;) May 27 16:29:42 pessi: That case is nasty, I have no immediate ideas on how to fix, feel free to prose something May 27 16:30:04 i just sent a patch to list May 27 16:32:51 pessi: Ok looks fine to me May 27 18:07:51 denkenz, yang_office: do you think it makes sense to have only one struct and one function for the 8 envelope pdu builders? the only common element for the envelopes is the Device Identities May 27 18:09:36 balrog-k1n: what about the command details? May 27 18:10:16 denkenz: evelopes don't have them May 27 18:10:43 e.g. Menu Selection just has device identities, item identifier and whether help is requested May 27 18:10:46 so you're proposing to treat each envelope as a separate struct, but include device id in each May 27 18:10:53 yep May 27 18:10:58 sounds fine to me May 27 18:11:50 In reality we can actually do this with proactive commands too May 27 18:12:40 However, it is convenient to have 1 struct with the type being along for the ride May 27 18:12:53 Otherwise you'd need to pass the type in May 27 18:13:32 yes, the common struct may be useful in the future, for example we may want to generate a template response for a command (fill in the command details and device ids) May 27 18:14:22 for envelopes its a bit easier since we only generate them May 27 18:14:38 yeah, and there are only 8 May 27 18:14:47 You'd need a _to_pdu for each one, but we can live with that May 27 18:15:05 However, if we ever have to parse envelopes, it becomes an issue May 27 18:15:29 so better to have a common struct? May 27 18:15:56 Lets do that for now, if it looks bad then we can change easily May 27 18:16:00 ok May 27 18:16:55 how close are we to being able to try out the setup menu stuff with phonesim? May 27 18:18:17 we need an envelope for the Menu Selection and a DBus api May 27 18:18:25 i think the api is quite obvious May 27 18:21:15 i have little interactive ofono client that could display the menu easily May 27 18:34:03 balrog-k1n: Sorry ISP dumped on me May 27 18:34:52 balrog-k1n: So just the envelope generator, dbus api and potentially a formatter for text attributes May 27 18:45:22 balrog-k1n: a formatter in ofono? May 27 18:45:48 Yeah, my current thought is that we should just format everything into HTML May 27 18:45:51 ah, because text attributes is a byte array May 27 18:46:23 denkenz: i was saying i have a little interactive ofono client where i could add the menu display easily May 27 18:46:36 it could convert from some dbus struct to html, or take html directly May 27 18:46:51 nice May 27 18:48:02 i don't know if sending ready html is a good idea, May 27 18:48:26 one issue is that current trend is for html to not contain style elements except embedded css, May 27 18:48:45 I don't want to expose the silly text attribute in binary form though May 27 18:48:45 the other issue is it can have javascript and i'm not sure if people using ofono will want to validate it before sending it to browser May 27 18:48:59 er, javascript? May 27 18:49:31 yeah, i mean, will client authors trust that the html send by ofono doesn't do anything nasty? May 27 18:49:37 sent* May 27 18:50:12 aw c'mon, who else can they trust? :) May 27 18:50:47 ok maybe that is too paranoid May 27 18:50:59 seriously, there are other problems, we are not running in user session, so even things like icons / images need to be passed around May 27 18:51:23 My current thinking is to dump it all into HTML, with images mime-encoded in the html stream May 27 18:51:45 With a decent browser all you need is to point to the produced output May 27 18:57:21 my thinking was to expose the attributes as some kind of dbus dictionary (possibly using css keys and values) and only bitmaps as bytes May 27 18:57:41 if you were writing a gtk client, i'm not sure how you'd embed a browser for every menu position and capture the clicks May 27 18:59:15 There are actually several cases May 27 18:59:24 one is display idle text May 27 18:59:36 where just plain html + icons is enough May 27 18:59:43 I agree menus are trickier May 27 19:00:41 still, separating the attributes from the text is a bad idea May 27 19:04:41 maybe custom xml that looks like html but doesn't use the same tags May 27 19:05:26 or xml with embedded html May 27 19:05:27 abc, then you can embed that in html and just say and it'll be like html May 27 19:06:25 that could work May 27 19:06:43 I nominate you to lead this effort ;) May 27 19:07:14 aww :) May 27 19:07:45 i'm not sure about the mime-encoded images though, can this be done so that a w3c validator will not complain? May 27 19:08:02 there are a couple of standards May 27 19:08:13 At least mozilla supports one May 27 19:08:30 Not sure about webkit May 27 19:08:42 I figure we don't care about any others May 27 19:11:34 also note that the text attribute crap is re-used from EMS May 27 19:11:46 So in theory we can also do rich-format SMS crap May 27 19:34:52 akiniemi: Feel free to take out the NITZ support task from the TODO May 27 19:35:11 pessi: Can you assign yourself to the Online mode task? May 27 19:35:31 pessi: See my reply to Pasi **** ENDING LOGGING AT Fri May 28 03:00:14 2010