**** BEGIN LOGGING AT Thu Jul 15 02:59:56 2010
Jul 15 18:34:26 <balrog-k1n> denkenz: i totally agree with all your comments to the text_to_html patches
Jul 15 18:35:26 <balrog-k1n> all non style-related comments anyway :)
Jul 15 18:35:52 <balrog-k1n> and also with the alpha id patch from yang_office
Jul 15 18:37:06 <balrog-k1n> the reason empty alpha id and no alpha id didn't matter for us so far was that with no alpha id the TE can optionally inform the user or not
Jul 15 18:37:27 <balrog-k1n> so if you ignore the alpha id in both of these cases you're still compliant
Jul 15 18:45:31 <inakypg> denkenz: ping
Jul 15 18:54:36 <denkenz> balrog-k1n: The reason for my question about alpha id is that I want to avoid clients doing stuff like:
Jul 15 18:54:52 <denkenz> if (id == NULL || id[0] == '\0')
Jul 15 18:54:58 <denkenz> inakypg: pong
Jul 15 18:55:39 <inakypg> denkenz: the SMS reorg is causing me lotta trouble; anyway, most of them sorted out, the main one is the msg_id being crafted inside the ofono_sms_txq_submit() function
Jul 15 18:56:02 <inakypg> denkenz: causes I can't generate a state change signal properly when the message is queued
Jul 15 18:56:20 <inakypg> because I can't initialize the D-Bus object until I have the msg_id
Jul 15 18:56:40 <denkenz> I wouldn't bother emitting the message id
Jul 15 18:56:53 <inakypg> wel, the msg_id is part of the D-Bus path, that was the whole idea
Jul 15 18:56:56 <inakypg> so the thing is unique
Jul 15 18:57:06 <inakypg> that was your initial request
Jul 15 18:57:22 <denkenz> sorry I'm not getting it
Jul 15 18:57:48 <inakypg> your initial request was to have the D-Bus path to the SMS Message object be /MODEMPATH/MSG-ID
Jul 15 18:57:50 <denkenz> send_message -> txq_submit, register, return make_path_from_msg()
Jul 15 18:58:20 <inakypg> denkenz: now when we do it like that, the D-Bus wrapper to send message initializes the whole D-Bus stuff right after send_msg returns
Jul 15 18:58:22 <inakypg> all that is good
Jul 15 18:58:39 <inakypg> but the problem is that the state machine for the message starts working as soon as _submit() is called
Jul 15 18:58:48 <inakypg> that calls the D-Bus state change callback, which emits the signal
Jul 15 18:59:00 <inakypg> so we always will miss the first state transition because by that time D-Bus is not initialized
Jul 15 18:59:14 <inakypg> sort of manually calling it, I have no other sollution with the current lay out
Jul 15 18:59:20 <inakypg> wondered if there is anything else you'd prefer
Jul 15 18:59:42 <denkenz>         g_queue_push_tail(sms->txq, entry);
Jul 15 18:59:42 <denkenz>         if (g_queue_get_length(sms->txq) == 1)
Jul 15 18:59:42 <denkenz>                 sms->tx_source = g_timeout_add(0, tx_next, sms);
Jul 15 18:59:58 <denkenz> The queue isn't started until the next event loop
Jul 15 19:00:47 <denkenz> pseudocode your flow for me?
Jul 15 19:00:52 <denkenz> I'm not sure I'm seeing the issue
Jul 15 19:05:12 <denkenz> Remember, g_timeout_add isn't immediate, this isn't the kernel
Jul 15 19:06:17 <inakypg> denkenz: sec, brb
Jul 15 19:07:55 <denkenz> balrog-k1n: See if you can incorporate the text_to_html stuff into the STK Menus.  Your browser based tool is perfect for this
Jul 15 19:10:32 <inakypg> denkenz: code flow in D-Bus wrapper is sms_msg_send() called, returns a tx_queue_entry (changed from returning a msg_id), builds the D-Bus stuff to export the message. A new callback added for state changes is used to send signals on D-Bus 
Jul 15 19:10:52 <inakypg> denkenz: because the process is not: object creation, object submit but object creation+submit
Jul 15 19:11:09 <inakypg> the D-Bus creation cannot be split either and thus the first state transition is missed on D-Bus
Jul 15 19:11:52 <denkenz> So when a new SMS is created, its status is pending
Jul 15 19:11:54 <denkenz> Right?
Jul 15 19:12:19 <inakypg> yap, pending / queued, same thing
Jul 15 19:12:42 <denkenz> Ok, do you attempt to emit the PropertyChanged with 'Pending'?
Jul 15 19:13:20 <inakypg> denkenz: we should be doing so, but it is missed because right at that time, the D-Bus stuff hasn't been initialized yet, as we need an object to do so
Jul 15 19:13:49 <denkenz> So we actually don't emit Properties on object creation
Jul 15 19:13:59 <inakypg> which is fine
Jul 15 19:14:02 <denkenz> There's really no reason to
Jul 15 19:14:05 <inakypg> the problem is the current code creates the object
Jul 15 19:14:07 <inakypg> and then submits it
Jul 15 19:14:23 <inakypg> if it where just creation, that's fine because the state would be 'idle' or whatever
Jul 15 19:14:31 <inakypg> now the momento we submit, the object goes live and moves to submitted
Jul 15 19:14:37 <inakypg> that we should report
Jul 15 19:15:18 <denkenz> pm me your git tree, I'm lost :P
Jul 15 19:15:33 <denkenz> What are the SMS message object states?
Jul 15 19:16:09 <inakypg> tree: still not committed, it is currently a hackfest
Jul 15 19:16:38 <denkenz> then pastebin the latest sms.c
Jul 15 19:16:43 <denkenz> pastebin.ca or something
Jul 15 19:16:51 <inakypg> SMS message objects: another thing we discussed already: .... IDLE / QUEUED / WAITING-FOR-SR / DONE / CANCELING /CANCELLED / FAILED / EXPIRED
Jul 15 19:17:31 <denkenz> What's the difference between IDLE and QUEUED?
Jul 15 19:17:52 <inakypg> precisely. IDLE, actually is called uninitialized is 'object created, not yet submitted'
Jul 15 19:18:14 <inakypg> denkenz: http://pastebin.ca/1901243
Jul 15 19:18:28 <inakypg> start at dbus_SendMessage
Jul 15 19:18:31 <denkenz> So why bother? once its on the queue its queued
Jul 15 19:19:38 <inakypg> I tend to disagree -- in any case, that's what transpired out of our latest conversations on the topic of the state machine for SMS Messages
Jul 15 19:22:15 <denkenz> See, I'd just do it exactly like how we're doing it today, something like:
Jul 15 19:22:18 <denkenz> sms_text_prepare
Jul 15 19:22:23 <denkenz> set_ref_and_to
Jul 15 19:22:26 <denkenz> sms_txq_submit
Jul 15 19:22:38 <denkenz> build_path_from_tx_entry()
Jul 15 19:22:48 <denkenz> dbus_message_new_method_return
Jul 15 19:22:57 <denkenz> append_path(sms_path)
Jul 15 19:23:09 <denkenz> Eliminate the IDLE state, its useless
Jul 15 19:25:41 <inakypg> *shrug* ok
Jul 15 19:26:37 <denkenz> Remember that unless there's an *actual* usecase for an application you have in mind, it is better to leave something out
Jul 15 19:28:01 <inakypg> there is a use case for having an IDLE/uninitialized state in place; allows you to detect an structure that is not initialized and the code can fail/crash accordingly. That's the whole point for it.
Jul 15 19:28:48 <denkenz> Who's going to put it on the queue?
Jul 15 19:29:05 <denkenz> We have very clearly defined entry points for everything to prevent such paranoia
Jul 15 19:29:16 <denkenz> e.g. internal __ofono api
Jul 15 19:29:18 <inakypg> currently it is that same function because creation and submission are done by the same entity (the basis I disagree on)
Jul 15 19:30:14 <denkenz> Again, the point is to keep it simple and understandable
Jul 15 19:30:34 <denkenz> Any 'hypothetical' reason gets discarded automatically
Jul 15 19:30:45 <denkenz> If there's a need for it, we add it later
Jul 15 19:30:54 <inakypg> ok, we are ratholing here, I'll remove that state and hack it aronud the current code
Jul 15 19:31:33 <denkenz> Good, also keep in mind there are no all-cap definitions in DBus APIs oFono exposes
Jul 15 19:31:53 <inakypg> What do you mean?
Jul 15 19:31:56 <denkenz> and stuff like: dbus_SendMessage won't get past the style filter
Jul 15 19:32:17 <denkenz> case OFONO_SMS_TX_ST_UNINITIALIZED:     return "UNINITIALIZED";
Jul 15 19:32:31 <denkenz> if that gets exposed as a property, it can't be all caps
Jul 15 19:32:39 <inakypg> ok, I'll change those to low caps
Jul 15 19:32:50 <inakypg> case* bah :)
Jul 15 19:34:34 <denkenz> Also, you might want to set the ofono_sms_msg_stch_cb_t stch_cb elsewhere and not expose it in the private API
Jul 15 19:34:42 <denkenz> Nobody except send_message really cares
Jul 15 19:36:50 <inakypg> it is a parameter to txq_submit
Jul 15 19:37:06 <inakypg> because that is in ofono.h already, it has to go there
Jul 15 19:37:34 <denkenz> That's my point, take it out
Jul 15 19:37:45 <denkenz> txq_submit is fine the way it is
Jul 15 19:38:01 <denkenz> Nobody except send_message can take advantage of the state changes
Jul 15 19:38:24 <inakypg> well, how do I hook up then the D-Bus propery_change notifications for state changes?
Jul 15 19:38:47 <denkenz> Just hack into the txq_entry in send_message or something
Jul 15 19:39:00 <inakypg> you and your hacks
Jul 15 19:39:17 <inakypg> ok, I'll hack it
Jul 15 19:39:19 <denkenz> I just want to keep txq_submit somewhat clean
Jul 15 19:39:28 <denkenz> Even internal API should be 'nice' to use
Jul 15 19:39:45 <inakypg> well, by hacking we'll keep that function clean and the rest of the code hacky. Nothing to win there.
Jul 15 19:40:09 <inakypg> anyway, my plan was to remove the current callback and replace it with the state change callback
Jul 15 19:40:15 <inakypg> as it provides more information
Jul 15 19:40:18 <inakypg> and can be used for the same purpose
Jul 15 19:40:47 <denkenz> txq_submit only really cares about the submission to the network
Jul 15 19:41:05 <denkenz> Trust me here, its serving its purpose just fine now ;)
Jul 15 19:41:37 <inakypg> oh, I don't refuse that, but it is not serving the purpose of creating the D-Bus interface the way it was discussed and agreed upon because it is creating AND submitting
Jul 15 19:42:10 <denkenz> So do the D-Bus registration elsewhere
Jul 15 19:42:22 <denkenz> However, we still need to keep a 'raw' submission function
Jul 15 19:42:32 <denkenz> There are other SMS messages which won't get exposed to D-Bus
Jul 15 19:42:51 <denkenz> e.g. the SMS-PP Downloads which txq_submit is being used for today
Jul 15 19:54:43 <inakypg> denkenz: and that's the whole idea behind keeping it separate and having all those callbacks. The D-Bus thing can be fully detached and kept in the ->data and callbacks, so internal messages don't show up in the bus.
Jul 15 19:55:21 <inakypg> but for doing that, it'd be way easier if the "message object''s life cycle were: msg_handle = create message and then somewhere later sumit_message(msg_handle)
Jul 15 20:14:34 <balrog-k1n> denkenz: my idea to handle the alpha id was for stk.c to call Agent::DisplayText or another method
Jul 15 20:15:04 <balrog-k1n> so clients don't need to decide what to do
Jul 15 20:16:53 <denkenz> balrog-k1n: Fair enough, but you still need to do that if conditional for every command except setup call
Jul 15 20:17:36 <denkenz> I mean I'm fine either way, just question of what is easier
Jul 15 20:19:34 <denkenz> inakypg: Fair enough, however I tend to like solutions where there are no 'invalid' states
Jul 15 20:19:39 <balrog-k1n> denkenz: there's a single function in stk.c to set the alpha id where i think it should be decided
Jul 15 20:20:41 <denkenz> balrog-k1n: Ok, works for me
Jul 15 20:24:15 <inakypg> denkenz: so are you saying I should go ahead and split the sms-message life cycle into create / submit?
Jul 15 20:26:03 <denkenz> I only really care that the current sms_txq_submit behavior is unchanged
Jul 15 20:26:28 <denkenz> I need a raw submit function for SMS-PP, and possibly VCards and VCals
Jul 15 20:27:23 <inakypg> denkenz: not splitting means a hack for the state change callback -- splitting just means that instead of a single call, there are two: one to create the message, one to submit it -- I would take care of chahing the only current site that uses it.
Jul 15 20:27:57 <denkenz> I'm against having clients do this
Jul 15 20:28:05 <denkenz> the semantics of txq_submit shouldn't change
Jul 15 20:28:14 <denkenz> If txq_submit makes 2 function calls, I'm fine
Jul 15 20:28:35 <inakypg> ok, then that sollution doesn't work
Jul 15 20:28:40 <inakypg> I'll hack it
**** ENDING LOGGING AT Fri Jul 16 02:59:56 2010