I can adapt the patch if you wish, just write which variant you want to use.
On Thu, Dec 16, 2021 at 7:12 PM Alexander Zubkov <[email protected]> wrote: > > I suspected, that the syntax may raise questions, but some syntax > should have been chosen to make a working patch. :) It does not matter > much to me, of course it could be changed in the way you prefer to see > it your product. > Yes, communities are not arrays, but on the other hand positional > addressing of fields is also intuitive and understandable, so I do not > see it as a big problem. For dot-notation is better to stick with > official names, like you suggest. I, personally, would prefer > something without subscription signs as they take more time to type > :), for example: global, data1, data2. And do you know something > suitable for standard communities? The best I can think of is "high" > and "low". As for EC communities, I did not even touched them, I do > not have experience with them and they look overcomplicated :), but > dot-notation I think should be better for them, as it will allow to > choose different representations. > > On Thu, Dec 16, 2021 at 6:34 PM Ondrej Zajicek <[email protected]> wrote: > > > > On Thu, Dec 16, 2021 at 02:41:28PM +0100, Alexander Zubkov wrote: > > > Hi everyone! > > > > > > I made a couple of patches to do some interesting stuff with communities. > > > The first patch allows to pick a component from a standard or a large > > > community: > > > > > > (10, 20, 30) @ 2 --> 20 > > > > > > And the second patch allows to search for minimum or maximum element > > > in a community list. This combined allows to do some cool stuff with > > > communities like this: > > > > > > bgp_local_pref = filter(bgp_large_community, [(<as>, <localpref_val>, > > > *)]).min @ 3 > > > > > > This will find us the minimum from our "localpref" communities and get > > > that number as integer, ready to assign it where we need. Now we use a > > > series of if's to check all the possible variants and that is not very > > > convenient. I think this features will greatly boost the possibilities > > > of working with communities in bird. > > > > Hi > > > > Nice patches, thanks! I agree that these features are pretty useful. > > Will merge the second one with no comments. > > > > With the first one, i do not really like the syntax. (Large) communities > > are not arrays to access them with indexing operator, and also using '@' > > as indexing operator is pretty unortodox. These are regular structures, > > so it is natural to use structure field accessors. Question is how these > > fields should be named, perhaps: global_id, data_1, data_2? > > > > That would make: > > > > (10, 20, 30) . global_id --> 10 > > (10, 20, 30) . data_1 --> 20 > > > > -- > > Elen sila lumenn' omentielvo > > > > Ondrej 'Santiago' Zajicek (email: [email protected]) > > OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) > > "To err is human -- to blame it on a computer is even more so."
