speechd-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[RFC] speech dispatcher client/server data types


From: Andrei Kholodnyi
Subject: [RFC] speech dispatcher client/server data types
Date: Mon, 4 Oct 2010 17:34:46 +0200

On Mon, Oct 4, 2010 at 5:11 PM, William Hubbs <w.d.hubbs at gmail.com> wrote:
> Hi Andrei,
>
> On Mon, Oct 04, 2010 at 04:35:43PM +0200, Andrei Kholodnyi wrote:
>> On Mon, Oct 4, 2010 at 4:02 PM, William Hubbs <w.d.hubbs at gmail.com> wrote:
>> > Hi Andrei,
>> >
>> > On Mon, Oct 04, 2010 at 08:43:09AM -0500, Christopher Brannon wrote:
>> >> Andrei Kholodnyi <andrei.kholodnyi at gmail.com> writes:
>> >>
>> >> > My proposal would be to align these data types
>> >> > and use the data types definitions from the libspeechd across all
>> >> > project modules
>> >> > with a clear advantage of consistency in data types between client and 
>> >> > server.
>> >>
>> >> We have a trade-off.
>> >> I can see the advantage: consistency.
>> >> The disadvantage is coupling. ?If someone ever needs to change one of
>> >> those shared types, it must change in both the client and server, even
>> >> if there's a good reason for changing it in only one component.
>> >
>> > Also, when you change a type in the client, you have to bump the shared
>> > library revision number.
>>
>> Yes, and what is bad about it? We are talking about server core data types.
>> E.g. if I decide to modify a priority and introduce "Emergency"
>> priority on the server side.
>> It is clear that I need to support it on the client side as well,
>> hence modify a lib revision number.
>
> But what if this priority is "server message" or something that only
> the server would use? ?You still have to add it to the type
> declarations. Since the type declarations are shared, this will force a
> revision number change.

it is a valid point, however if you look at speech dispatcher's
development history
after 10 years of development we have ended up with exactly the same
data types but called differently.

I'd rather give it a try now and if some problems arise in the future
/which is a quite hypothetical case now/
we could always split it.

>> >> Also, sharing declarations means that components of Speech Dispatcher
>> >> could not be separated into subprojects, if the need ever arises.
>> >
>> > The way to do this, imho, would be to copy the types from libspeechd.h
>> > to some place in the include directory, but also leave them in
>> > libspeechd.h so the API and server sides are not forced to share
>> > the type declarations. ?Sharing these type declarations is the thing I
>> > am uncomfortable with about your proposal, not the actual data types.
>>
>> ok, could you please then suggest how it should look like? the same
>> data types in two different headers?
>
> That's correct, one copy in libspeechd.h and the other in
> speechd_types.h.
>
>> My concern is also that we need to export two headers now,
>> one for the clients (libspeechd.h), another for the modules
>> (speechd_types.h) with the similar data types.
>> With my proposal these two will be merged in one.
>
> Actually we aren't exporting anything at all to support out of tree
> modules, and setting up for that is a topic for another thread.

Yes, this would be good to discuss as well, please send an RFC :D
I think we need to export some headers and a protocol between server
and modules.

Andrei.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]