[PATCH 03/09] replace EPunctMode with SPDPunctuation

[Andrei Kholodnyi]

It is a strange discussion where I'm asking "please explain why do you
think that it is not a good idea to have the same data types on both
ends" and you answers "I think it is not a good idea"

So I'm asking again: please explain why do you think it is a good idea
to have on the client side e.g SPDPriority type and on the server side
"int" type for exactly the same data?
I'm wondering whether you have dropped a look in the source code?


On 10/4/10, William Hubbs <w.d.hubbs at gmail.com> wrote:
> Hi Andrei,
>
> On Sun, Oct 03, 2010 at 09:48:53PM +0200, Andrei Kholodnyi wrote:
>> are represented by different data types on client/server side.
>> e.g. SPDPunctuation/EPunctMode, SPDPriority/int and so on.
>> And this makes no sense to me.
>
> They are represented by even a third data type, the one that goes over
> the wire, which is actually ascii strings (look at the ssip document for
> that information).
>
>> If I'd follow your "separation needs" I'd expect e.g. having different
>> data types e.g. by socket programming on client/server side.
>> But they are the same, William.
>
>  I'm not following this statement; I do not know what you mean.
>
>> I have SPDPunctuation data on my client side,
>> I send it over network to the server, it arrives on the server side,
>> what type of data should I expect to get?
>
> Actually, what happens is, you use SPDPunctuation on your client.  That
> gets converted to "some" "most" or "all" before it even gets sent to the
> server.  So SPDPunctuation does not get sent over the wire at all.
>
> The server then receives those strings and handles them however it wants
> to.  Yes, because the api and the server are both in C they use the
> enums to handle the data, but that is not a feature of the protocol.
>
> Take a look at the python API to see what it sends over the wire and
> also look at the SSIP document.
>
> If we force the server and API to use the same enums for everything,
> that will create a very strong coupling between them, which I do not
> think is a good idea.
>
> Also, keep in mind that if we put all of our server and api types in one
> source file, it becomes confusing at best to know when we have to
> increment the API shared library revision.
>
> William
>
>

-- 
Sent from my mobile device

Believe is not enough, you must know