[PATCH] Filter: picking community elements and finding min/max element

[Alexander Zubkov]

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 <green at qrator.net> 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 <santiago at crfreenet.org> 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: santiago at crfreenet.org)
> > OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
> > "To err is human -- to blame it on a computer is even more so."