On Wed, 2011-10-19 at 13:20 +0300, Colin Guthrie wrote: > Hi, > > As a general comment, I'd rather avoid introducing a new naming > convension with the "ABOUT_TO_ACTIVATE" suffix. > > We already have _POST, _START and _FINISH suffixes on some hooks, so I'd > suggest either a _PRE suffix to match _POST or perhaps just reusing > _START (tho' _START does seem to imply there will be a corresponding > _FINISH so maybe _PRE is better?) > > Or maybe we should just rename PA_CORE_HOOK_CARD_PROFILE_CHANGED to > PA_CORE_HOOK_CARD_PROFILE_CHANGE_FINISH and then call the new one > _START? Opinions welcome here. > > Other than that, provided this doesn't conflict in any major way with > anything David's been doing, this seems fine. One possibility would be CARD_PROFILE_ACTIVATING. I think that would imply that it's fired prior to the actual activation. That's my vote currently :) I'd like to keep profile change and profile activation as separate concepts - I think profile change is an operation done on the card, while profile activation is an operation done on the card profile. With the current code there is no practical distinction, however, because the profile changing is not divided to separate phases for deactivation of the old profile and activation of the new profile. From that point of view it would be sufficient and fine to have eg. CARD_PROFILE_CHANGE_START and CARD_PROFILE_CHANGE_FINISH. But in the long term I hope the profile change process will be divided to separate deactivation and activation phases, so that the card will enter an intermediate state for the duration of the profile change. By "intermediate state" I mean a state that will be visible also to the clients etc. That intermediate state is needed, because the profile change may require waiting for some external component, and it would be good if the execution could return to the event loop for the duration of that wait. The module that I'm working on will have to wait for a reply from bluetoothd before the profile activation can continue, so the main thread will be blocked while waiting for a reply. This is currently unavoidable with the "atomic" profile changing logic. This is not a new problem - I believe there is similar stuff (synchronous D-Bus calls) happening in the bluetooth modules already now (I don't know or remember the details, but I have had some discussion about this with Luiz). -- Tanu
