On 2016-05-27 13:29, Erik Hugne wrote:
> On May 27, 2016 10:13, "Richard Alpe" <richard.a...@ericsson.com> wrote:
>>
>> On 2016-05-26 19:58, Erik Hugne wrote:
>>>> .ti -8
>>>> +.B tipc bearer add remoteip REMOTEIP media udp name NAME
>>>
>>> Why is the parameter order different from "bearer enable"?
>>>
>>> tipc bearer enable media udp localip xxx name yyy?
>>>
>>> Or can you specify it in this order when adding replicast remoteips
> aswell?
>> I assume you mean that the parameter and value comes before the media
>> and name here.
>>
>> I spend quite a lot of time thinking about this. The parameters will
>> work in a different order. However, I'm still not sure what the
>> supported way should be and I'm open for suggestions / input.
>>
>> The reasoning is that { media MEDIA { dev DEV | name NAME } is the
>> bearer identifier. And looking at how other commands like get and set
>> works they take the bearer identifier last. It's only enable that
>> doesn't.
>>
>> $ tipc bearer set priority 123 media udp name foo
>> $ tipc bearer set priority 123 media eth dev eth0
>> $ tipc bearer get priority media udp name foo
>> $ tipc bearer get priority media eth dev eth0
>>
>> These are global bearer options we set and get. So it makes sense to
>> have them before identifying the bearer/media. However, when I in
>> this patch-series introduced some UDP bearer dependent options my
>> first implementation had them after the bearer identifier.
>>
>> # UDP specific options comes after the identifier
>> $ tipc bearer set media udp name foo remoteip 1.2.3.4
>> $ tipc bearer get media udp name foo remoteip
>> $ tipc bearer add media udp name foo remoteip 1.2.3.4
>>
>> # Global options comes before the bearer identifier (today)
>> $ tipc bearer set priority 123 media udp name foo
>> $ tipc bearer get priority media udp name foo
>>
>> Looking at these I just assumed the user would find it hard to use and
>> confusing that the option is passed in a different place depending on
>> its type. It's also not clear to me what we actually set/get here.
>> Everywhere else in the tipc tool we do "set foo bar" where foo is what
>> we set. Like "node set address 1.2.3". I.e. the key we set/get is always
>> passed after the set/get word.
>>
>> So, do you vote for having bearer specific options after the identifier?
>> $ tipc bearer set priority 123 media udp name foo
>> $ tipc bearer set media udp name foo remoteip 1.2.3.4
>> $ tipc bearer add media udp name foo remoteip 1.2.3.4
>>
>
> yes. I usually try to think of the syntax as a tree, more specific options
> at the "bottom". This have the added benefit that parameters that are
> irrellevant for what you want to do can easily be filtered out in the tab
> completion.
Yes, your right. It makes something easier and logically it makes sense.
Checked with a couple of collages and everyone agree that all commands
except perhaps bearer enable, which you can argue is different. Works with
"action key" and doing this breaks the consistency. Which is bad.
This is what we can set/get today:
$ tipc bearer set priority X media udp name foo
$ tipc bearer set tolerance X media udp name foo
$ tipc bearer set window X media udp name foo
$ tipc bearer get priority media udp name foo
$ tipc bearer get tolerance media udp name foo
$ tipc bearer get window media udp name foo
$ tipc link set tolerance X link Y
$ tipc link set priority X link Y
$ tipc link set window X link Y
$ tipc link set tolerance X link Y
$ tipc link set priority X link Y
$ tipc link set window X link Y
$ tipc node set address X
$ tipc node set netid Y
$ tipc node get address
$ tipc node get netid
I really don't want to break this consistency. I mean following
your argument the entire API is wrong.
For example:
$ tipc link set tolerance X link Y
should have been
$ tipc link set link X tolerance Y.
/Richard
>
> //E
>
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
