Hi Erik,
On 2016-05-27 15:34, Richard Alpe wrote:
> 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.
I have slept on this now and I think your right Erik. As soon as I get
some time I will re-implement it the way you prefer and hopefully it
will turn out good :)
/Richard
>
> 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
>
------------------------------------------------------------------------------
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
