[PATCH] merge SPDNotification into SPDNotificationType

[Andrei Kholodnyi]

On Mon, Sep 27, 2010 at 1:58 PM, Christopher Brannon
<cmbrannon79 at gmail.com> wrote:
> Andrei Kholodnyi <andrei.kholodnyi at gmail.com> writes:
>
>> ?typedef enum{
>> - ? ?SPD_BEGIN = 1,
> *SNIP*
>> + ? ?SPD_EVENT_BEGIN = 1,
>
> My inclination is to put this aside for a while.
> It breaks backward compatibility, requiring both a soname bump and
> possible changes to existing clients. ?Of course, I'm always willing to
> go against my inclinations, given a good reason to do so.

I'm fine on that.
I think we need to prepare a list of changes we want to make on libspeechd API,
agree on them and then implement them.

e.g. I do not like "set ALL" functions.
As Trev has mentioned and I support him on that, set functions shall
be related to particular client only.
"get ALL" functions are probably ok.

>> + ? ?SPD_EVENT_ALL = 0x3F
>
> I really like this! ?I would write it differently:
> SPD_EVENT_ALL = SPD_EVENT_BEGIN | SPD_EVENT_END | ... | SPD_EVENT_RESUME;
> But that's a matter of style.

this part is actually a bugfix.
on the server side you have in set_notification_self

    }else if (!strcmp(type, "all"))
        {
            SET_NOTIFICATION_STATE(END);
            SET_NOTIFICATION_STATE(BEGIN);
            SET_NOTIFICATION_STATE(IM);
            SET_NOTIFICATION_STATE(CANCEL);
            SET_NOTIFICATION_STATE(PAUSE);
            SET_NOTIFICATION_STATE(RESUME);
        }

but you never reach it from the libspeechd, since it is not
implemented on the client side.

I have tried to add "all" capability to SPDNotification and ended up with a name
SPD_ALL (similar to SPD_BEGIN etc.) which makes no sense to me.

Give me a better name and I'll provide a separate patch for it. :D

Andrei.